On Sat, Mar 8, 2025, at 1:05 AM, Edmond Dantes wrote:
Hello all.
A few thoughts aloud about the emerging picture.
### Entry point into the asynchronous context
Most likely, it should be implemented as a separate function (I haven't
come up with a good name yet), with a unique name to ensure its
behavior does not overlap with other operators. It has a unique
property: it waits for the full completion of the event loop and the
Scheduler.Inside the asynchronous context, `Fiber` is prohibited, and conversely,
inside a `Fiber`, the asynchronous context is prohibited.
Yes.
### The `async` operator
The `async` (or *spawn*?) operator can be used as a shorthand for
spawning a coroutine:
This is incorrect. "Create an async bounded context playpen" (what I called "async" in my example) and "start a fiber/thread/task" (what I called "spawn") are two *separate* operations, and must remain so.
create space for async stuff {
start async task a();
start async task b();
}
However those get spelled, they're necessarily separate things. If any creation of a new async task also creates a new async context, then we no longer have the ability to run multiple tasks in parallel in the same context. Which is, as I understand it, kinda the point.
I also don't believe that an async bounded context necessarily needs to be a function, as doing so introduces a lot of extra complexity for the user when they need to manually "use" things. (Though perhaps sometimes we can have a shorthand for that; that comes later.)
I am also still very much against allowing tasks to "detach". If a thread is allowed to escape its bounded context, then I can no longer rely on that context being bounded. It removes the very guarantee that we're trying to provide. There are better ways to handle "throwing off a long-running background task." (See below.)
Edmond, correct me if I'm wrong here, but in practice, the *only* places that it makes sense to switch fibers are:
1. At an otherwise-blocking IO call.
2. In a very long running CPU task, where the task is easily broken up into logical pieces so that we can interleave it with shorter tasks in the same process. This is only really necessary when running a shared single process for multiple requests.
And in this proposal, IO operations auto-switch between blocking and thread-sharing as appropriate.
To be more concrete, let's consider specific use cases that should be addressed:
1. Multiplexing IO, within an otherwise sync context like PHP-FPM
I predict that, in the near term, this will be the most common usage pattern. (Long term, who knows.) This one is easily solvable; it's basically par_map() and variations therein.
// Creates a context in which async is allowed to happen. IO operations auto
async $ctx = new AsyncContext() {
$val1 = spawn task1();
$val2 = spawn task2();
// Do stuff with those values.
}
// We are absolutely certain nothing started in that block is still running.
(I'm still unclear if $val1 and $val2 should be values or a Future object. Possibly the latter.)
4. Shared-process async server
This is the ReactPHP/Swoole space. This... honestly gets kind of easy.
Wrap the entire application in an async {} block. Boom. All IO is now async.
<?php
async {
while (true) {
$request = spawn listen_for_request();
spawn handle_request($request);
}
}
Importantly, since IO is the primary switch point, and IO automatically deals with thread switching, my DB-query-heavy Repository object doesn't care if I'm doing this or not. If each $handler (controller, whatever) is written 100% sync, with lots of IO... it still works fine.
3. Set-and-forget background job
This is the logger example, but probably also queue tasks, etc. This is where the request for detaching comes from. I would argue detaching is both the wrong approach, and an unnecessary one. Because you can send data to fibers from OTHER contexts... via channels.
So rather than this:
spawn detatch log('message'); // Who the hell knows when this will complete, or if it ever does.
We have this:
async {
$logger = new AsyncLogger();
$channel = $logger->inputChannel();
spawn handler($logChannel);
}
function handler($logger) {
async {
while (true) {
$request = spawn listen_for_request();
spawn handle_request($request, $logChannel);
} // An exception could get us to here.
}
}
function handle_request($request, $logChannel) {
$logChannel->send($request->url());
// Do other complex stuff with the request.
}
This is probably not the ideal way to structure it in practice, but it should get the point across. The background logger fiber already exists in the parent async playpen. That's OK! We can send messages to it via a channel. It can keep running after the inner async block ends. The logger fiber doesn't need to be attached, because it was already attached to a parent playpen anyway!
This means passing either a channel-enabled logger instance around (probably better for BC; this should be easy to do behind PSR-3) or the sending channel itself. I'm sure someone will object that is too much work. However, it is no more, or less, work than passing a PSR-3 logger to services today. And in practice "your DI container handles that, stop worrying" is a common and effective answer.
An async-aware DI Container could have an Async-aware PSR-3 logger it passes to various services like any other boring PSR-3 instance. That logger forwards the message across a channel to a waiting parent-playpen-bound fiber, where it just enters the rotation of other fibers getting run.
Services don't need to be modified at all. We don't need to have dangling fibers. And for smaller, more contained cases, eh, Go has shown that "just pass the channel around and move on with life" can be an effective approach. The only caveat is you can't pass a channel-based logger to a scope that will be called outside of an async playpen... But that would be the case anyway, so it's not really an issue.
There's still the context question, as well as whether spawn is a method on a context object or a keyword, but I think this gets us to 80% of what the original RFC tries to provide, with 20% of the mental overhead.
--Larry Garfield