7b30e788bb
Delaying activation of watchers to the next tick guarantees consistent behavior between all implementations. Additionally it eliminates the following problem: - Two defer()'s are set up with the first one immediately disabled - Second defer()'s callback is called and enables the first defer()'s watcher - Executes defer() in same tick or next tick? If the answer is same tick, what happens in the following scenario: - An immediately disabled defer() and a delay($msDelay = 0) are set up - The delay()'s callback enables the defer()'s watcher - Executes defer() callback in same tick or next tick? Doing it in same tick violates the requirement that defers are called before any other watchers in the same tick. We get similar problems with e.g. delay() and repeat() (if their timer all expired now, but we require order to be preserved). Thus we need to pretty much delay the activation of enable() to the next tick to avoid potential ambiguity or different behaviors depending on when exactly the enable() or watcher registration happened. |
||
|---|---|---|
| src | ||
| test | ||
| .gitignore | ||
| .travis.yml | ||
| composer.json | ||
| LICENSE | ||
| phpunit.xml | ||
| README.md | ||
Event Loop Interopability
The purpose of this proposal is to provide a common interface for event loop implementations. This will allow libraries and components from different vendors to operate in an event driven architecture, sharing a common event loop.
Why Bother?
Some programming languages, such as Javascript, have an event loop that is native to the execution environment. This allows package vendors to easily create asynchronous software that uses this native event loop. Although PHP is historically a synchronous programming environment, it is still possible to use asynchronous programming techniques. Using these techniques, package vendors have created PHP event loop implementations that have seen success.
However, as these event loop implementations are from package vendors, it is not yet possible to create event driven software components that are independent of the underlying event loop implementation. By creating a common interface for an event loop, interoperability of this nature will be possible.
Goals
The functionality exposed by this interface should include the ability to:
- Watch input streams for available data
- Watch output streams for the ability to perform non-blocking write operations
- Run single and periodic timers
- Listen for signals
- Defer the execution of callables