Re: RFC proposal: worker mode primitives for SAPIs

Hi, On Tue, Dec 26, 2023 at 12:09 AM Robert Landers <landers.robert@gmail.com> wrote: > Hi Jakub, > > > I have been thinking about something similar for FPM and if you had some > > sort pool manager process, you could maybe do some sort of initial > > execution but then it gets really tricky especially with sharing > resources > > and managing connections. I think it would be a big can of worms so I > don't > > think this is going to happen anytime soon. > > It's already happening. Most libraries (particularly popular ones in > the Symfony/Laravel world) already support most of this > out-of-the-box. I love stateless servers, but sometimes a stateful > server is better. What is really nice about worker mode is that you > can actually have a PHP-native in-memory database that only exists for > as long as the worker is running (I do this for some unit tests). > > This was just about FPM. What I meant that this is not going to be supported by FPM anytime soon if ever. > > I could imaging that there will > > be similar issues for Apache prefork which is likely the most used MPM > for > > legacy apps. Effectively it means that this function won't be working on > > most installations as two of the likely most used SAPI's won't support > it. > > I think it should be pretty clear from the beginning. > > Most people are familiar with fastcgi_finish_request() and there are > some built-in SAPI's that don't support it. I don't think that just > because it won't start out with full support, it should be discarded. > > I didn't mean that it shouldn't be added. It should just be clear from the beginning that this will be for limited set of SAPIs. > > It would be also good to put together some base design PR for this as > > currently SAPI common functions are implemented separately in each SAPI > > (e.g. apache_request_headers). From the linked functionality, it is is > not > > a big amount of code and seems somehow specific to the FrankenPHP so why > > couldn't each SAPI just implement this function separately? I know that > > this is not ideal but it's what is already used for > apache_request_headers. > > I think otherwise you would need some hooking mechanism that should have > > some default (which would probably just throw exception) because it is > not > > going to be implemented by all SAPI's. I think it would be really good if > > you could provide more details about planned implementation for this. > > Most (all?) modern SAPI (lightspeed, roadrunner, etc) implements > fastcgi_finish_request(), even if no fastcgi is involved, simply > because of backward compatibility. It'd be great to actually bikeshed > a decent name and syntax/semantics before something popular comes > along and forces us all to use frankenphp_handle_request() or > something, simply because of backward compatibility. > I agree that coming up with some sensible name and API would be a good think even though it will have limited use in core. And if it gives us some coverage of embed SAPI (libphp), then it's even better. Cheers Jakub