On 08/03/2025 22:28, Daniil Gentili wrote:
Even its use is optional, its presence in the language could lead
library developers to reduce concurrency in order to allow calls from
async blocks, (i.e. don't spawn any background fiber in a method call
because it might be called from an async {} block) which is what I
meant by crippling async PHP.
I think you've misunderstood what I meant by optional. I meant that
putting the fiber into the managed context would be optional *at the
point where the fiber was spawned*.
A library wouldn't need to "avoid spawning background fibers", it would
simply have the choice between "spawn a fiber that is expected to finish
within the current managed scope, if any", and "spawn a fiber that I
promise to manage myself, and please ignore anyone trying to manage it
for me".
There have been various suggestions of exactly what that could look
like, e.g. in https://externals.io/message/126537#126625 and
https://externals.io/message/126537#126630
The naming of "async {}" is also very misleading, as it does the
opposite of making things async, if anything it should be called
"wait_all {}"
Yes, "async{}" is a bit of a generic placeholder name; I think Larry was
the first to use it in an illustration, and we've been discussing
exactly what it might mean. As we pin down more precise suggestions, we
can probably come up with clearer names for them.
The tone of your recent e-mails suggests you believe someone is forcing
this precise keyword into the language, right now, and you urgently need
to stop it before it's too late. That's not where we are at all, we're
trying to work out if some such facility would be useful, and what it
might look like.
It sounds like you think:
1) The language absolutely needs a "spawn detached" operation, i.e. a
way of starting a new fiber which is queued in the global scheduler, but
has no automatic relationship to its parent.
2) If the language offered both "spawn managed" and "spawn detached",
the "detached" mode would be overwhelmingly more common (i.e. users and
library authors would want to manage the lifecycle of their coroutines
manually), so the "spawn managed" mode isn't worth implementing.
Would that be a fair summary of your opinion?
--
Rowan Tommins
[IMSoP]
