On Mon, Dec 25, 2023 at 7:06 PM Kévin Dunglas <ke...@dunglas.fr> wrote:
> > On Mon, Dec 25, 2023 at 6:30 PM Jakub Zelenka <bu...@php.net> wrote: > >> >> >> On Mon, Dec 25, 2023 at 12:34 PM Kévin Dunglas <ke...@dunglas.fr> wrote: >> >>> On Sun, Dec 24, 2023 at 4:21 PM Larry Garfield <la...@garfieldtech.com> >>> wrote: >>> >>> In practice, I want to understand the implications for user-space code. >>> > Does this mean FPM could be configured in a way to execute a file like >>> that >>> > shown in the docs page above? Or would it only work with third party >>> SAPIs >>> > like FrankenPHP? >>> >>> >>> In theory, PHP-FPM and the Apache module could - like all other SAPIs - >>> be >>> enhanced to add a worker mode operating as described in the FrankenPHP >>> doc >>> thanks to these new primitives. >>> >> >> 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. 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. >> >> >>> However, I suggest doing this as a second step, because as described in >>> my >>> first post, it will still be the responsibility of each SAPI to manage >>> long-running processes and communication with them. This is simple to do >>> with Go's GoRoutine and Rust's asynchronous runtimes such as Tokio, it's >>> definitely more difficult in cross-platform C. I suggest starting by >>> adding >>> the primitives to libphp, then we'll see how to exploit them (and whether >>> it's worthwhile) in the built-in SAPIs. >>> >> >> The problem with this is that we would add some code that won't be used >> by any of the built in SAPI which means that that we won't be able to have >> automated tests for this. So the minimum should be to have at least one >> core SAPI supporting this new functionality. I wouldn't mind if it's just a >> SAPI for testing purpose which might be actually useful for testing embed >> SAPI code. I think that should be a requirement for accepting a PR >> introducing this. >> >> 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. >> >> >>> I personally have less interest in working on FPM/CGI/mod_php as the >>> other >>> possibilities offered by modern SAPIs like FrankenPHP are more important >>> (better deployment experience as you have a single static binary or >>> Docker >>> image, Early Hints support, high-quality native HTTP/3 server etc) >>> >>> >> Except that those are all threaded SAPIs so they offer less separation >> and protection against application crashes in addition to the fact that >> thread management in PHP still has got its own issues. They are certainly >> some advantages especially for thin services but if you have huge monolith >> codebase like some big CMS and other projects, then I would probably stick >> with process separation model. >> >> Cheers >> >> Jakub >> > > Sure, the main targets are new SAPIs like FrankenPHP and the one in Rust > developed by the RoadRunner team. I thought it was clear in my previous > messages but I'll be glad to make it bold in the RFC. > The way how I read was that this would be eventually supported by all SAPIs which I think is not likely going to be the case. > Automated tests (likely through a test SAPI) will definitely be needed. > Throwing if the current SAPI doesn't support (yet) the new userland > function looks sensitive. > > +1 > Couldn't this shared code be put in "main", as it could (theoretically, I > agree that it will be hard to do for existing core SAPIs) be used by all > SAPIs? > The main does not have a module but it could be probably added to standard ext like it's the case for other functionality related to main. Cheers Jakub
