Weave Code
Event Loop Laravel Package
revolt/event-loop
Revolt is a rock-solid event loop for concurrent PHP applications. Powered by PHP 8.1 fibers, it enables cooperative multitasking and non-blocking I/O without callbacks or promises, offering a common scheduler base for Amp, ReactPHP, and other libraries.
Rock-solid event loop for concurrent PHP applications.
Frequently asked questions about Event Loop
- What is revolt/event-loop used for in a Laravel application?
- It provides the single global event loop needed for PHP 8.1 fiber-based cooperative multitasking. In Laravel it is most useful in long-lived processes such as queue consumers, WebSocket or SSE servers, scheduler daemons, and batch jobs that make many parallel outbound I/O calls. It is not an application framework and does not replace HTTP clients, database drivers, or servers; those come from libraries built on top such as Amp v3.
- Is revolt/event-loop compatible with Laravel 10, 11, and 12?
- Yes at the dependency level: it supports PHP 8.1 through 8.4 and has no Laravel version lock, service provider, or container coupling. Compatibility does not mean every Laravel workload benefits, because standard FPM/nginx requests remain synchronous and process-per-request. The real fit is standalone daemons and CLI-facing packages, not typical web request lifecycles.
- How do I install revolt/event-loop in Laravel?
- Install it with composer require revolt/event-loop on PHP 8.1 or later. There is no service provider to register and no Laravel configuration file to publish. You then write or adopt code that uses EventLoop::queue(), delay(), repeat(), onReadable(), onWritable(), onSignal(), or getSuspension() directly.
- Do I need ext-uv, ext-ev, or ext-event for Revolt?
- Not strictly, but applications with many concurrent file descriptors should use one of these extensions. The stream_select fallback is historically capped around 1024 file descriptors and can burn CPU under load. Check your production base image so you do not get a silent fallback you did not intend.
- Can I use revolt/event-loop inside Laravel Octane with Swoole or RoadRunner?
- Do not layer Revolt inside Octane workers that already run Swoole coroutines or RoadRunner's Go loop, because that puts two concurrency models in one process and invites deadlocks. Revolt's natural home is standalone php artisan daemons and CLI packages. For Octane, use the runtime's own concurrency primitives or keep Revolt-dependent work outside those workers.
- Will Revolt make Eloquent and PDO database queries non-blocking?
- No. PDO and typical Eloquent MySQL access are blocking, so a query stalls the single event-loop thread and collapses the concurrency gains. You need fiber-aware drivers such as amphp/mysql or a proxied or sidecar data-access pattern. That is a data-access layer change, not just a scheduler install.
- What are the main production risks of revolt/event-loop?
- The highest-probability risk is blocking-call poisoning from PDO, ext-curl, file_* functions, proc_open, sleep(), mail, and some session handlers. Other risks include missing event extensions, resource leaks from suspensions that are never resumed, and fiber-boundary issues tied to specific PHP versions. The package is stable at the 1.0 line, but treat the fiber boundary as where PHP-version risk concentrates.
- How does revolt/event-loop compare with Amp and ReactPHP?
- Revolt is not a full concurrency framework; it is the common scheduler base that Amp v3, ReactPHP, and other libraries can build on. Amp and ReactPHP remain opinionated libraries built on top, providing clients, drivers, pools, and servers. Choose Revolt directly only when you need the scheduling primitive; choose Amp when you want the broader ecosystem and accept that it brings Revolt along.
- How should I test Laravel code that uses the Revolt event loop?
- The event loop is a global singleton, so implicit state can complicate test isolation and mixing with other runtimes. Structure tests to boot and shut down the loop deliberately, and watch for unresumed suspensions, which retain fibers and can trigger shutdown assertions. Prefer small units around your loop lifecycle and integration tests for daemons rather than assuming the loop is isolated automatically.
- When should I avoid revolt/event-loop in a Laravel project?
- Avoid it in standard FPM/nginx request lifecycles where the process is already per-request and synchronous, because adding a loop does not remove blocking calls and any remaining blocking call stalls everything. Also avoid it when your critical path is Eloquent/PDO against MySQL without fiber-aware drivers, or when you cannot own loop lifecycle, graceful shutdown, and rollback. It is a latency and throughput lever for I/O-bound daemons, and a no-op everywhere else.
Weaver
How can I help you explore Laravel packages today?