Hi, Nicolas.
Hi Edmond,
The target DX is that when outside any event loop, we're still able to
leverage fibers to provide concurrency, for requests only, and when inside
an event loop, requests run concurrently to any other things that the loop
monitors.
Is that something that could be achieved with your proposal?
If not, maybe that's the split we're wondering about?
This RFC leads to PHP operating in two modes:
Blocking mode: The Event Loop needs to be implemented manually, AMPHP
works. This is how PHP currently operates.
Concurrent mode: Code runs in coroutines. The Event Loop works under the
hood. AMPHP does not work.
If we try to imagine a way to keep PHP in a single mode, it would likely
require implementing coroutines separately from Fiber and leaving Fiber as
legacy.
This solution has both advantages and disadvantages.
Advantages:
Switching can be optimized considering the new architecture.
The Event Loop will start automatically when needed.
Code using Fiber will work as before, and most likely, AMPHP will be able
to create an event loop in user-land.
Disadvantages:
More work is required.
There is a risk of ending up with a Frankenstein-like result. :)
A relative advantage of the current implementation is that it changes only
about 100-500 lines in the PHP core (probably even fewer, since part of the
changes are in extensions like CURL and Socket).
The downside is that it cannot change the rules that were previously
established.
--
Ed.
