Download the PHP package toalett/multiprocessing without Composer

🚽 Toalett

Welcome to Toalett, a humble initiative based around the idea that all software is 💩.
Toalett is the Norwegian word for toilet. It feels fancier than plain "toilet".

Why toalett/multiprocessing?

Multiprocessing is a technique that is often used in PHP (cli) applications to execute tasks asynchronously. Due to the lack of native multithreading in PHP, developers have to rely on good old multiprocessing to do this.

We often see code that's written in a quick and dirty way to accomplish this task, with calls to pcntl_fork() hidden somewhere, leading to ugly implementations.

Toalett has nothing against quick and dirty PHP code, but since multiprocessing so common, it might be nice to use this library.

Okay, how do I use it?

Install it with composer:

Structure

The library provides a single class to manage multiprocessing: the Context. It uses react/event-loop internally and emits events using the simple (but elegant) evenement/evenement library. It delegates tasks to the internal Workers component, which in turn is responsible for creating and managing child processes.

Creating a Context

This library comes with the ContextBuilder class which is used to build a Concurrency limit (defaults to unlimited), a custom instance of \React\EventLoop\LoopInterface and an Interval at which a cleanup of child processes should be performed. To create a Context, you simply call the build() method:

Submitting a job

Use the Context::submit method to submit a job:

Jobs are not executed until the Context::run method is called.
In order to execute this job 5 times, using at most two processes, we would do:

If you want to submit a job using an interval, you are encouraged to use a custom event loop instead of sleep() or usleep() to prevent blocking the main process (and thus pausing the event loop):

Events

The context emits events when something of interest happens. You can add event listeners using the Context::on method:

These are the events emitted by the context:

1. booted
2. worker_started
3. worker_stopped
4. congestion
5. congestion_relieved
6. no_workers_remaining
7. stopped

1. The booted event

This event is emitted after $context->run() is called. This is the very first event dispatched by the context. It is dispatched as soon as the event loop has started.

2. The worker_started event

This event is emitted when a worker has been started (the process has been forked). The PID of the child process is supplied as an argument to a listener.

3. The worker_stopped event

This event is emitted when a worker has been stopped (child process has stopped). The PID of the child process is supplied as an argument to a listener.

4. The congestion event

This event is emitted when the imposed concurrency limit is reached. This happens when (for example) the concurrency is set to at most 2 child processes, and a third task gets submitted while 2 tasks are already running. The system naively waits for a child to stop before starting another worker.

5. The congestion_relieved event

This event is emitted when congestion is relieved. This means that a child has stopped, allowing for the execution of a new task.

6. The no_workers_remaining event

This event is emitted when there are no workers left running. This usually means there is no more work to do. It's possible to automatically stop the context when this event occurs. This is shown in the first and last example.

7. The stopped event

The context can be stopped by calling Context::stop. When the workers and the event loop are succesfully stopped, the context emits a stopped event.

Examples

For most developers, the quickest way to learn something is by looking at examples. Three executable examples are provided.

Counting stopped workers using events

This is a simple example, which demonstrates event emission with the creation of 50 jobs. A counter is incremented every time a job stops. When all jobs are done, the context is stopped.

The cleanup interval may be set to a low value to improve responsiveness.

Triggering congestion with 4 workers

This example is a bit more elaborate than the previous one. It serves to demonstrate congestion and how it is handled by the context: the context simply blocks all execution until a worker stops and a spot becomes available.

Watch for the occurence of 'C' in the output. This denotes congestion: a worker could not be started.

Single worker with a Job class

Since a task is really just a Closure, it's also possible to submit an object with an implementation of the __invoke() magic method.

In this example, execution is limited to a single worker, and jobs are instances of the Job class.

Tests

Tests can be found in the src/Tests directory.