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 <[email protected]> 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.