On Wed, Mar 5, 2025, at 3:37 AM, Edmond Dantes wrote:
Good day, Larry.
First off, as others have said, thank you for a thorough and detailed proposal.
Thanks!
* A series of free-standing functions.
* That only work if the scheduler is active.
* The scheduler being active is a run-once global flag.
* So code that uses those functions is only useful based on a global state not present in that function.
* And a host of other seemingly low-level objects that have a myriad of methods on them that do, um, stuff.
* Oh, and a lot of static methods, too, instead of free-standing functions.
Suppose these shortcomings don’t exist, and we have implemented the
boldest scenario imaginable. We introduce Structured Concurrency,
remove low-level elements, and possibly even get rid of `Future`. Of
course, there are no functions like `startScheduler` or anything like
that.
1. In this case, how should PHP handle `Fiber` and all the behavior
associated with it? Should `Fiber` be declared deprecated and removed
from the language? What should the flow be?
I'm not sure yet. I was quite hesitant about Fibers when they went in because they were so low-level, but the authors were confident that it was enough for a user-space toolchain to be iterated on quickly that everyone could use. That clearly didn't pan out as intended (Revolt exists, but usage of it is still rare), so here we are with a half-finished API.
Thinking aloud, perhaps we could cause `new Fiber` to create an automatic async block? Or we do deprecate it and discourage its use. Something to think through, certainly.
2. What should be done with I/O functions? Should they remain
blocking, with a separate API provided as an extension?
The fact that IO functions become transparently async when appropriate is the best part of the current RFC. Please keep that. 
3. Would it be possible to convince the maintainers of XDEBUG and
other extensions to rewrite their code to support the new model? ( *If
you're reading this question now, please share your opinion.* )
I cannot speak for Derick.
4. If transparent concurrency is introduced for I/O in point 2, what
should be done with `Revolt` + `AMPHP`? This would break their code.
Should an additional function or option be introduced to switch PHP
into "legacy mode"?
Also an excellent question, to which I do not yet have an answer. (See previous point about Fibers being half-complete.) I would want to involve Aaron, Christian, and Ces-Jan before trying to make any suggestions here.
Structured concurrency is a great thing. However, I’d like to avoid
changing the language syntax and make something closer to Go’s
semantics. I’ll think about it and add this idea to my TODO.
Well, as noted in the article, structured concurrency done right means *not* having unstructured concurrency. Having Go-style async and then building a structured nursery system on top of it means you cannot have any of the guarantees of the structured approach, because the other one is still poking out the side and leaking. We're already stuck with mutable-by-default, global variables, and other things that prevent us from making helpful assumptions. Please, let's try to avoid that for async. We don't need more gotos.
async $context {
// $context is an object of AsyncContext, and can be passed around as such.
// It is the *only* way to span anything async, or interact with the async controls.
// If a function doesn't take an AsyncContext param, it cannot control async. This is good.
This is a very elegant solution. Theoretically.
However, in practice, if you require explicitly passing the context to
all functions, it leads to the following consequences:
1. The semantics of all functions increase by one additional parameter
(*Signature bloat*).
No, just those functions/objects that necessarily involve running async control commands. Most wouldn't. They would just silently context switch when they hit an IO operation (which as noted above is transparency supported, which is what makes this work) and otherwise behave the same.
But if something does actively need to do async stuff, it should have a context to work within. It's the same discussion as:
A: "Pass/inject a DB connection to a class that needs it, don't just call a global db() function."
B: "But then I have to pass it to all these places explicitly!"
A: "That's a sign your SQL is too scattered around the code base. Fix that first and your problem goes away."
Explicit flow control is how you avoid bugs. It's also self-documenting, as it's patently obvious what code expects to run in an async context and which doesn't care.
2. If an asynchronous call needs to be added to a function, and other
functions depend on it, then the semantics of all dependent functions
must be changed as well.
This is no different than DI of any other service. I have restructured code to handle temporary contexts before. (My AttributeUtils and Serde libraries.) The result was... much better code than I had before. I'm glad I made those refactors.
In this example, there is another aspect: the fact that async execution
is explicitly limited to a specific scope. This is essentially the same
as `startScheduler`, and it is one of the options I was considering.
Of course, `startScheduler` can be replaced with a construction like
`async(function() { ... })`.
This means that async execution is only active within the closure, and
coroutines can only be created inside that closure.
This is one of the semantic solutions that allows removing
`startScheduler`, but at the implementation level, it is exactly the
same.
What do you think about this?
That looks mostly like the async block syntax I proposed, spelled differently. The main difference is that the body of the wrapped function would need to explicitly `use` any variables from scope that it wanted, rather than getting them implicitly. Whether that's good or bad is probably subjective.
But it would allow for a syntax like this for the context, which is quite similar to how database transactions are often done:
$val = async(function(AsyncContext $ctx) use ($stuff, $fn) {
$result = ;
foreach ($stuff as $item) {
$result = $ctx->run($fn);
}
// We block/wait here until all subtasks are complete, then the async() call returns this value.
return $result;
});
And of course in both cases you could use a pre-defined callable instead of inlining one. At this point I think it's mostly a stylistic difference, function vs block.
I'm not convinced that sticking arbitrary key/value pairs into the Context object is wise;
Why not?
that's global state by another name
Static variables inside a function are also global state. Are you
against static variables?
Vocally, in fact.
But if we must, the above would handle all the inheritance and override stuff quite naturally. Possibly with:
How will a context with open string keys help preserve service data
that the service doesn't want to expose to anyone? The `Key()` solution
is essentially the same as `Symbol` in JS, which is used for the same
purpose. Of course, we could add a `coroutine static $var` construct to
the language syntax. But it's all the same just syntactic sugar that
would require more code to support.
I cannot speak to JS Symbols as I haven't used them. I am just vhemently opposed to globals, no matter how many layers they're wrapped in. Most uses could be replaced by proper DI or partial application.
[$in, $out] = Channel::create($buffer_size);
This semantics require the programmer to remember that two variables
actually point to the same object. If a function has multiple channels,
this makes the code quite verbose. Additionally, such channels are
inconvenient to store in lists because their structure becomes more
complex.
I would suggest a slightly different solution:
<code php>
$in = new Channel()->getProducer();
async myFunction($in->getConsumer());
<code>
This semantics do not restrict the programmer in usage patterns while
still allowing interaction with the channel through a well-defined
contract.
I'd go slightly differently if you wanted to go that route:
$ch = new Channel($buffer_size);
$in = $ch->producer();
$out = $ch->consumer();
// You do most interaction with $in and $out.
I could probably work with that as well.
(Or even just $ch->inPipe and $ch->outPipe, now that we have nice property support.)
But the overall point, I think, is avoiding implicit modal logic. If my code doesn't need to care if it's in an async world, it doesn't care. If it does, then I need an explicit async world to work within, rather than relying on one implicitly existing, I hope. And I shouldn't have to think about "who owns this end of this channel". I just have an in and out hose I stick stuff into and pull out from, kthxbye.
Thanks for the great examples, and a special thanks for the article.
I also like the definition of context.
Ed
--Larry Garfield