On Mon, Dec 25, 2023, at 6:34 AM, Kévin Dunglas wrote: > 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. > 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), but I'd be happy to help if anyone wants to update these > SAPIs.
>> To what extent would user-space code run this way have to think about >> concurrency, shared memory, persistent SQL connections, etc? Does it have >> any implications for fiber-using async code? > > Regarding concurrency, it doesn't change much (it's similar to existing > SAPI). Regarding memory and SQL connections, extra care is required. > Memory leaks (and other kinds of leaks) should be avoided (or workers > should restart from time to time, which is obviously a poorer > solution). Libraries maintaining SQL connections such as Doctrine or > Eloquent must ensure that the connection isn't active. Forgive my ignorance, but why no connection? You mean the pre-worker-start part needs to avoid an SQL connection? Why is that? That would be something that needs to be super-well documented, and possibly some guards in place to prevent it, if there's no good way around it. (This is the sort of detail I'm thinking of, where I just don't know the implications but want to think through them as much as possible in advance, so that it can be "safe by design.") > Fibers work as expected. There is a small limitation when using them > with Go (that is being tracked in the Go runtime, > https://frankenphp.dev/docs/known-issues/#fibers), but it's not related > to the C code of the worker mode, and this limitation shouldn't exist > for SAPIs not written in Go. > >> Depending on the details, this could be like fibers but for 3rd party SAPIs >> (something about 4 people in the world actually care about directly, >> everyone else just uses Revolt, Amp, or React, but mostly it doesn't get >> used), or completely changing the way 90% of the market runs PHP, which >> means frameworks will likely adapt to use that model primarily or >> exclusively (ie, less of a need for a "compile" step as a generated >> container or dispatcher is just held in memory automatically already). The >> latter sounds exciting to me, but I'm not sure which is your intent, so I >> don't know if I'm going too far with it. :-) > > My intent is that most SAPIs expose the same (or a very similar > interoperable) worker mode. So (I hope) that most PHP developers will > not have to deal with these primitives directly, but that it will allow > a new generation of super-fast PHP apps to be created. Most frameworks > already support that but require a lot of boilerplate code to support > the different existing engines. Standardizing will likely increase > adoption and will allow collaboration to make the low-level code that I > propose to move in libphp as fast, stable, and clean as possible. Do you have an intent or expectation of a worker-style SAPI being shipped with PHP itself, or for that to remain the domain of third parties? >> Please advise on what the implications would be for the non-SAPI-developing >> PHP devs out there. > > None, except that they will be able to use the new handle_request() > function to create a worker script if supported by the SAPI they use. I mean more what implications would there be on how user-space code is written to be worker-SAPI-friendly. (The SQL connection comment above, for example.) I have not worked with any of the worker-ish tools so far myself, so other than "you'll need an alternate index.php for that", I don't have a good sense of what else I'd want to do differently to play nice with Franken and Friends. The idea of combining fiber-based code with supported worker-mode runners sounds like a ridiculously cool future for PHP, but I don't know how windy that path is. :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
