Re: PHP True Async RFC

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.gentili@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.