On Sun, Dec 31, 2023 at 2:20 AM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> On 30 December 2023 19:48:39 GMT, Larry Garfield <la...@garfieldtech.com> > wrote: > >The Franken-model is closer to how PHP-FPM works today, which means that > is easier to port existing code to, especially existing code that has lots > of globals or hidden globals. (Eg, Laravel.) That may or may not make it > the better model overall, I don't know, but it's the more-similar model. > > That's why I said earlier that it provides better backwards compatibility > - existing code which directly uses PHP's current global state can more > easily be run in a worker which populates that global state. > > However, the benefit is marginal, for two reasons. Firstly, because in > practice a lot of applications avoid touching the global state outside of > some request bootstrapping code anyway. The FrankenPHP example code and > Laravel Octane both demonstrate this. > > Secondly, because in an environment that handles a single request at a > time, the reverse is also possible: if the server passes request > information directly to a callback, that callback can populate the > superglobals as appropriate. The only caveat I can think of is input > streams, since userland code can't reset and populate php://input, or > repoint STDOUT. > > On the other hand, as soon as you have any form of concurrency, the two > models are not interchangeable - it would make no sense for an asynchronous > callback to read from or write to global state. > > And that's what I meant about FrankenPHP's API having poor forward > compatibility - if you standardise on an API that populates global state, > you close off any possibility of using that API in a concurrent > environment. If you instead standardise on callbacks which hold request and > response information in their own scope, you don't close anything off. > > If anything, calling this "forwards compatibility" is overly generous: the > OP gave Swoole as an example of an existing worker environment, but I can't > see any way that Swoole could implement an API that communicated request > and response information via global state. > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php This new function is intended for SAPIs. Swoole was given as an example of worker mode, but it isn't a SAPI. AFAIK, it doesn't use the SAPI infrastructure provided by PHP. The scope of my proposal is only to provide a new feature in the SAPI infrastructure to build worker modes to handle HTTP requests, not to deal with non-SAPI engines. That being said, I don't understand what would prevent Swoole from implementing the proposed API, or even to implement a userland implementation of the proposed API using Swoole under the hood. It seems doable to emulate the sequential request handling and to create an adapter from their custom objects to superglobals and streams. For WebSockets and WebTransports, the same considerations apply. The SAPI API will have to be extended to deal with such low-level network layers, worker mode or not. To me, this is very interesting (and needed) but should be discussed in another RFC. As pointed out by Crell, FrankenPHP (and similar theoretical solutions) starts as many workers as needed. This can be a fixed set of workers, as in FrankenPHP, or a dynamic number of workers, similar to traditional FPM workers. FrankenPHP uses threads to parallelize request handling (to start several instances of the worker script in parallel). Other techniques could be used, for instance, in the future, we could use goroutines (which use a mix of system threads and async IO, and goroutines are handled in a single system thread: https://github.com/golang/go/blob/master/src/runtime/HACKING.md#gs-ms-ps) instead of threads, by adding a new backend to TSRM. The global state is never reset in the same worker context, it is preserved across requests, except for superglobals and streams, which are updated with the data of the request being handled. Superglobals are the PHP way to expose CGI-like data. Adding support for other ways to do it such as proposed by WSGI, and/or new objects and the like could be interesting, but again this isn't the scope of this proposal which is narrow, and tries to reuse the existing infrastructure as much as possible. The proposal is simple enough to support new ways if introduced at some point in PHP, and the Symfony Runtime and Laravel Octane libraries prove that it's possible to implement more advanced data structures user-land on top of the existing superglobals infrastructure. Regarding the infinite loop, we could indeed remove it using a few lines of code. I hesitated to do that initially, but the loop gives more flexibility by allowing the implementation of many features in user-land (like restarting the worker after a fixed number of requests, when the memory reaches a certain level, etc). Without this loop, all these features will require new C functions. I thought it was a simple and good way to give more power to user-land, at the price of some boilerplate code (that will in theory always be hidden in low-level libraries or bootstrap code). That being said, I've no strong opinion about that and would be open to removing the need for the while loop if we find a good way to keep the current flexibility. Best regards,
