On Fri, Jan 5, 2024 at 11:59 AM Rowan Tommins <rowan.coll...@gmail.com> wrote: > > On 5 January 2024 09:02:05 GMT, Robert Landers <landers.rob...@gmail.com> > wrote: > > I don't think they are fundamentally incompatible. If we look at > >FrankenPHP's implementation, you pass a callback that gets called when > >there is a request. > > No, you pass a callback which is called exactly once, for the next request. > You have to implement your own loop if you want to handle multiple requests, > which obviously isn't how it would work with an async event loop. > > That was one of my suggested changes: move the loop into C, so that the API > was "callback called for each request". This actually *adds* flexibility on > the server end, to decide how often to call that callback, do so > asynchronously, etc.
I think the goal here is to provide the basic building block: a function that takes a callable that, when called, blocks the script. Even when you have an event loop, there is some point when you call something and enter an infinite loop (the event loop), and no more of that file will be called ($app->start() or whatever). This is _that function_ for all intents and purposes. You can implement your own event-loop using do/while (such as in FrankenPHP), or a SAPI can call it in a loop for you. The bedrock is in core PHP, providing a standardized way of setting this up ... obviously, there are also SAPIs out there doing their own thing, and there always will be. > > Globals is how this works (atm) > > It's how it works for native SAPIs. It's not, as far as I know, how any > worker system other than FrankenPHP has implemented its API. Every other > implementation I've seen, whether async or not, passes in some form of > request data to the callback, with the exception of RoadRunner, which gives > the data as a return value from a "get next request" function. Nearly every library in existence knows how to use these globals (including 30 years old legacy code). There are also the unwieldy PSR request/response containers for which there are dozens (if not hundreds) of implementations. It would be fantastic if there were already an extension-based implementation that could be adopted into php-src; though I feel like that is a separate conversation. > So, the second suggested change is to standardise on the most common pattern > of passing parameters to a callback, rather than the unusual one of > populating and clearing superglobals. As a bonus, this pattern works with > both non-async and async workers. > > > > changing the signature of the callback is generally backwards compatible > > This is true in the narrow sense that it won't cause any fatal errors. But if > you write your application assuming that it will run in an environment where > globals are populated for you, it will not run in an environment which no > longer populates those globals. This is easy to handle from C. If the callback takes an argument, don't fill in the super-globals. It allows legacy apps to be slowly "upgraded" while allowing newer apps to take full advantage of a SAPI. That's how I would implement it, anyway. There is also something to be said to go "all the way" and just abandoning legacy apps, but that doesn't feel like something PHP would do. > >Changing the underlying implementation in php-src when there are > >native fibers/event loops probably won't even change anything (since > >that was exactly how they were designed). > > Sounds great! So we don't need to wait to put that implementation in place > then. > > > > >But holding up the entire conversation ... > > There is no reason whatsoever to hold anything up. The suggestion is not > "don't implement any worker API until we have an async implementation", it's > "a worker API sounds great, let's implement one that looks like this". > > Yes, it might take slightly longer to define some new array structures, but > we're talking about a few hours work to give us a much more flexible system, > not weeks of complex engineering. > > If the proposal is "copy some code from FrankenPHP into php-src, which nobody > else will want to use", it's pointless; if it's "standardise an API with some > enabling code", then *of course* we want to spend a bit of time designing > that API. That's fair. I was taking this push-back from you and others as, "No, we don't want this unless we can have all these other things," so thank you for clarifying that. I can largely agree -- I use amphp + fibers extensively in another project, so seeing more love for concurrent servers would be nice. Maybe I saw it that way because I have a fairly deep understanding of the shortcomings with fibers/async-php and see the amount of work required to support what you are proposing. However, if we go into the design with the concurrent server story in mind, I think we can create something much better than what is available from FrankenPHP. > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
