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). > 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. > 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 think this functionality unlocks some really cool potential powers (in-memory databases for development, connection pooling without an extension, etc) and it's worth at least seriously considering implementing it in core. - Rob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
