- Can I use Pokio to speed up Laravel migrations or Artisan commands?
- Yes, Pokio is perfect for parallelizing Laravel migrations or Artisan commands. It forks processes to run tasks concurrently, reducing total execution time for I/O-bound operations like database queries or API calls. Just wrap your migration steps in `async()` and `await()` the results.
- Will Pokio work in Laravel’s HTTP routes or API controllers?
- No, Pokio is **not designed for HTTP async**—it’s CLI-focused. It uses process forking (pcntl) and shared memory (FFI), which are unsafe for web requests. For HTTP async, use Laravel’s queues (Redis/SQS) or Swoole/ReactPHP instead.
- How do I install Pokio in a Laravel project?
- Run `composer require nunomaduro/pokio` in your project. Ensure your PHP environment has the **PCNTL** and **FFI** extensions enabled. If FFI is missing, install it via PECL (`pecl install ffi`) or Docker/PHP config. Pokio falls back to sequential execution if extensions are unavailable.
- Does Pokio support Laravel’s service container or dependency injection?
- Pokio works with plain closures, so you’ll need to manually bind dependencies or use static methods. For Laravel services, pass them as arguments to your async closures or resolve them inside. Avoid global state like singletons or static vars, as they won’t persist across forks.
- Is Pokio compatible with Xdebug for debugging Artisan commands?
- Yes, Pokio **automatically disables forking** when Xdebug is active (PR #49), ensuring seamless debugging. Your Artisan commands will run sequentially during debugging sessions, then switch to parallel mode in production-like environments.
- What happens if my CI environment lacks PCNTL or FFI support?
- Pokio gracefully falls back to sequential execution if PCNTL/FFI are missing. Wrap your `await()` calls in a try-catch block to log fallbacks or handle errors. Test your CI pipeline to ensure compatibility—some shared hosting or CI services disable these extensions by default.
- Can I use Pokio for long-running background tasks like WebSocket handlers?
- No, Pokio is **not suitable for long-running tasks**. Child processes are ephemeral, and shared memory (FFI) is process-local. For persistent background jobs, use Laravel Queues (Redis, SQS) or a dedicated worker like Swoole. Pokio is optimized for short-lived, I/O-bound tasks.
- How do I handle errors or retries in async tasks with Pokio?
- Pokio doesn’t include built-in retry logic. Use `catch()` blocks inside your async closures to handle failures, or wrap `await()` in try-catch to log errors. For retries, implement exponential backoff manually. Unlike queues, Pokio won’t automatically retry failed tasks.
- What are the memory/process limits I should consider when using Pokio?
- Each async task spawns a new PHP process, which can hit system limits (e.g., `ulimit` or OOM killer). Monitor child process counts and reduce parallelism if needed. For CI/local environments, test with `pcntl_set_max_children()` or batch tasks to avoid resource exhaustion.
- Are there alternatives to Pokio for parallelizing PHP tasks in Laravel?
- For CLI tasks, consider `popen()` or `pcntl_exec()` for simpler forking, or libraries like **Symfony Process** for subprocess management. For HTTP async, use **Swoole** or **ReactPHP**. If you need queues, Laravel’s built-in queue system (Redis, SQS) is more robust for production. Pokio is niche—best for internal tooling where simplicity trumps features.