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