>> To make an analogy, it's like saying PHP should have an io {} block, that
>> makes sure all file resources opened within (even internally, 10 stack
>> levels deep into 3 libraries, whose instances are all used after the io {}
>> block) are closed when exiting.
>
> Traditional PHP offers exactly this: the SAPI lifecycle tracks all file
> handles opened within a request, and closes them cleanly before reusing the
> thread or process for another request. Essentially what I'm proposing is a
> way to implement the same isolation in userland, by marking a checkpoint in
> the code.
Exposing this in userland offers an extremely dangerous footgun that will
severely limit concurrency.
> As I've said repeatedly, it doesn't necessarily need to be a mandatory
> restriction, it can be a feature to help users write code without having to
> worry about *accidentally* leaving a background fiber running.
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.
Libraries can and should handle cleanup of running fibers by themselves, on
their own terms, without externally imposed limitations.
It makes absolutely no sense, especially for a SAPI, to force all background
fibers to stop after a request is finished.
It would force users to stop and restart all running fibers on each request,
which is precisely the main argument for the use of worker mode: reducing
overhead by keeping caches primed, sockets open and background loops running.
PHP itself explicitly offers an escape hatch around the "io {} block" of
current SAPIs, in the form of persistent resources (and again, this is all for
performance reasons).
Even ignoring performance considerations, as I said many times, offering this
tool to userland is a major footgun that will either backfire spectacularly
(breaking existing and new async libraries by endlessly awaiting upon
background fibers when exiting an async {} block haphazardly used by a newbie,
or even worse force library developers to reduce concurrency, killing async PHP
just because users can use async {} blocks), or simply not get used at all
(because the main SAPI usecase listed explicitly does NOT need purity).
Regards,
Daniil Gentili.
