Hi,
To see to be posting a reply to nearly every other email on this thread. I'd
recommend you have another read through our mailing list rules:
<https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md>
cheers
Derick
On 8 March 2025 22:28:58 GMT, Daniil Gentili <daniil.gent...@gmail.com> wrote:
>>> 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.
