Event loops and supported backends

Backend selection in the reviewed source

EventLoopFactory accepts auto, linux, select, windows, revolt/fiber, event, ev, swoole, swow or an EventInterface implementation class. An explicitly requested unavailable backend throws RuntimeException; it is not silently replaced.

Automatic selection on Unix is event → ev → Revolt/Fiber → Select. Windows selects its Windows loop. Auto selection does not enable Swoole/Swow coroutine hooks globally; those require explicit selection. This order is a capability preference, not measured performance ranking.

Backend	Required capability
Select	Built-in stream-based fallback
event	ext-event and EventBase
ev	ext-ev and Ev
Revolt/Fiber	revolt/event-loop package
Swoole	ext-swoole and Swoole Event
Swow	ext-swow and Swow Coroutine

There is no ext-uv backend in this factory. Installing uv does not select a supported backend and does not prove performance. Old libuv-first diagrams/recommendations have been retired.

Inspect capabilities

php server.php capabilities --json

Run through the same entry point and PHP configuration as the service. EventLoopFactory::capabilities() reports backend availability, while Server capabilities also cover runtime process/upgrade support. Availability does not prove production limits or a complete backend test matrix.

Programming model

The loop owns readable/writable watchers, timers and supported signals. Register work and let it run; callbacks must return promptly. Blocking filesystem, HTTP or SQL remains blocking unless its implementation/runtime supplies async behavior. Timer::sleep only suspends with a suspension-capable backend in a supported context; the normal fallback uses usleep.

Use explicit lifetime ownership: remove watchers/timers and close resources when their owner ends. Test callback errors, cancellation, slow consumers and shutdown. See Timer and runnable recipes.