On Sat, Mar 1, 2025, at 10:11, Edmond Dantes wrote:
> Good day, everyone. I hope you're doing well.
>
> I’d like to introduce a draft version of the RFC for the True Async component.
>
> https://wiki.php.net/rfc/true_async
>
> I believe this version is not perfect and requires analysis. And I strongly
> believe that things like this shouldn't be developed in isolation. So, if you
> think any important (or even minor) aspects have been overlooked, please
> bring them to attention.
>
> The draft status also highlights the fact that it includes doubts about the
> implementation and criticism. The main global issue I see is the lack of
> "future experience" regarding how this API will be used—another reason to
> bring it up for public discussion.
>
> Wishing you all a great day, and thank you for your feedback!
>
Hey Edmond:
I find this feature quite exciting! I've got some feedback so far, though most
of it is for clarification or potential optimizations:
> A PHP developer *SHOULD NOT* make any assumptions about the order in which
> Fibers will be executed, as this order may change or be too complex to
> predict.
There should be a defined ordering (or at least, some guarantees). Being able
to understand what things run in what order can help with understanding a
complex system. Even if it is just a vague notion (user tasks are processed
before events, or vice versa), it would still give developers more confidence
in the code they write. You actually mention a bit of the order later
(microtasks happen before fibers/events), so this sentence maybe doesn't make
complete sense.
Personally, I feel as though an async task should run as though it were a
function call until it hits a suspension. This is mostly an optimization though
(C# does this), but it could potentially reduce overhead of queueing a function
that may never suspend (which you mention as a potential problem much later on):
Async\run(*function*() {
$fiber = Async\async(*function*() {
sleep <http://www.php.net/sleep>(1); // this gets enqueued now
return "Fiber completed!";
});
*// Execution is paused until the fiber completes*
$result = Async\await($fiber); // immediately enter $fiber without queuing
echo $result . "*\n*";
echo "Done!*\n*";
});
> Until it is activated, PHP code behaves as before: calls to blocking
> functions will block the execution thread and will not switch the *Fiber*
> context. Thus, code written without the *Scheduler* component will function
> exactly the same way, without side effects. This ensures backward
> compatibility.
I'm not sure I understand this. Won't php code behave exactly the same as it
did before once enabling the scheduler? Will libraries written before this
feature existed suddenly behave differently? Do we need to worry about the
color of functions because it changes the behavior?
> `True Async` prohibits initializing the `Scheduler` twice.
How will a library take advantage of this feature if it cannot be certain the
scheduler is running or not? Do I need to write a library for async and another
version for non-async? Or do all the async functions with this feature work
without the scheduler running, or do they throw a catchable error?
> This is crucial because the process may handle an OS signal that imposes a
> time limit on execution (for example, as Windows does).
Will this change the way os signals are handled then? Will it break
compatibility if a library uses pcntl traps and I'm using true async traps too?
Note there are several different ways (timeout) signals are handled in PHP --
so if (per-chance) the scheduler could always be running, maybe we can unify
the way signals are handled in php.
> Code that uses *Resume* cannot rely on when exactly the *Fiber* will resume
> execution.
What if it never resumes at all? Will it call a finally block if it is
try/catched or will execution just be abandoned? Is there some way to ensure
cleanup of resources? It should probably mention this case and how abandoning
execution works.
> If an exception is thrown inside a fiber and not handled, it will stop the
> Scheduler and be thrown at the point where `Async\launchScheduler()` is
> called.
The RFC doesn't mention the stack trace. Will it throw away any information
about the inner exception?
> The *Graceful Shutdown* mode can also be triggered using the function:
What will calling `exit` or `die` do?
> A concurrent runtime allows handling requests using Fibers, where each Fiber
> can process its own request. In this case, storing request-associated data in
> global variables is no longer an option.
Why is this the case? Furthermore, if it inherits from the fiber that started
its current fiber, won't using Resume/Notifier potentially cause problems when
used manually? There are examples over the RFC using global variables in
closures; so do these examples not actually work? Will sharing instances of
objects in scope of the functions break things? For example:
Async\run($obj->method1(...));
Async\run($obj->method2(...));
This is technically sharing global variables (well, global to that scope --
global is just a scope after all) -- so what happens here? Would it make sense
to delegate this fiber-local storage to user-land libraries instead?
> Objects of the `Future` class are high-level patterns for handling deferred
> results.
By this point we have covered FiberHandle, Resume, and Contexts. Now we have
Futures? Can we simplify this to just Futures? Why do we need all these
different ways to handle execution?
> A channel is a primitive for message exchange between `Fibers`.
Why is there an `isEmpty` and `isNotEmpty` function? Wouldn't
`!$channel->isEmpty()` suffice?
It's also not clear what the value of most of these function is. For example:
if ($chan->isFull()) {
doSomething(); // suspends at some point inside? We may not know when we
write the code.
// chan is no longer full, or maybe it is -- who knows, but the original
assumption entering this branch is no longer true.
...
}
Whether a channel is full or not is not really important, and if you rely on
that information, this is usually an architectural smell (at least in other
languages). Same thing with empty or writable, or many others of these
functions. You basically just write to a channel and eventually (or not, which
is a bug and causes a deadlock) something will read it. The entire point is to
use channels to decouple async code, but most of the functions here allow for
code to become strongly coupled.
As for the single producer method, I am not sure why you would use this. I can
see some upside for the built-in constraints (potentially in a dev-mode
environment) but in a production system, single-producer bottlenecks are a real
thing that can cause serious performance issues. This is usually something you
explicitly want to avoid.
> In addition to the `send/receive` methods, which suspend the execution of a
> `Fiber`, the channel also provides non-blocking methods: `trySend`,
> `tryReceive`, and auxiliary explicit blocking methods: `waitUntilWritable`
> and `waitUntilReadable`.
It isn't clear what happens when `trySend` fails. Is this an error or does
nothing?
Thinking through it, there may be cases where `trySend` is valid, but more
often than not, it is probably an antipattern. I cannot think of a valid reason
for `tryReceive` and it's usage is most likely guaranteed to cause a deadlock
in real code. For true multi-threaded applications, it makes more sense, but
not for single-threaded concurrency like this.
In other words, the following code is likely to be more robust, and not depend
on execution order (which we are told at the beginning not to do):
Async\run(*function*() {
$channel = *new* Async\Channel();
$reader = Async\async(*function*() *use*($channel) {
while ($data = $channel->read() && $data !== NULL) {
echo "receive: *$data**\n*";
}
});
for ($i = 0; $i < 4; $i++) {
echo "send: event data *$i**\n*";
$data = $channel->send("event data *$i*");
}
$reader->cancel(); // clean up our reader
// or
$channel->close(); // will receive NULL I believe?
});
A `trySend` is still useful when you want to send a message but don't want to
block if it is full. However, this is going to largely depend on how long is
has been since the developer last suspended the current fiber, and nothing else
-- thus it is probably an antipattern since it totally depends on the literal
structure of the code, not the structure of the program -- if that makes sense.
> This means that `trapSignal` is not intended for “regular code” and should
> not be used “anywhere”.
Can you expand on what this means in the RFC? Why expose it if it shouldn't be
used?
-----
I didn't go into the low level api details yet -- this email is already pretty
long. But I would suggest maybe thinking about how to unify
Notifiers/Resume/FiberHandle/Future into a single thing. These things are
pretty similar to one another (from a developer's standpoint) -- a way to
continue execution, and they all offer a slightly different api.
I also noticed that you seem to be relying heavily on the current
implementation to define behavior. Ideally, the RFC should define behavior and
the implementation implement that behavior as described in the RFC. In other
words, the RFC is used as a reference point as to whether something is a bug or
an enhancement in the future. There has been more than once where the list
looks back at an old RFC to try and determine the intent for discovering if
something is working as intended or a bug. RFCs are also used to write
documentation, so the more detailed the RFC, the better the documentation will
be for new users of PHP.
— Rob
