333a9daf5a
The registry allows to store information bound to a specific loop. This can be useful to store state of globals like a DNS resolver. Rationale for a global DNS resolver: Nobody wants to inject a resolver into everything that does some sort of I/O. Using IP addresses everywhere instead of hostnames also doesn't make sense. Therefore there should be a global default DNS resolver. But this resolver needs a read watcher for the response. If the loop gets swapped and a DNS request is made, the resolver would never get the read event, since the stream is only watched in the old loop. The resolver also doesn't get any info about the loop swap, so it can't use a new watcher. With a loop bound registry, it can just store the connection in the loop and will use a new connection when the loop is swapped, because the state doesn't exist any longer. Once the loop is put back, it can use the old connection again. This API should only be used by real global objects. Most packages won't need to use this API, but it's required for the mentioned use cases.
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