Hello Pierre, > but shouldn't the need be covered by the Scope RFC > https://wiki.php.net/rfc/scope
Not really, they solve different problems. The Scope RFC gives an identity to requests running concurrently in the same process. It doesn't provide a point where a request ends: as the RFC says, a scope doesn't finish when run() returns. It also only covers the superglobals, the session, the default locale and the default timezone. My proposal is a small internal refactoring that adds two optional hooks, called between two requests served one after the other by the same script. They let each extension release its own request state, which today worker SAPIs reset by poking into the extensions' globals. The bugs we fixed in FrankenPHP were in state the Scope RFC doesn't cover: strtok(), the last HTTP response headers, libxml errors, the request body. It's a quality of life improvement for the existing ecosystem (SAPIs with a worker mode and the extensions supporting them). Unlike the Scope RFC, it has no impact on userland code and requires no change to it. Worker modes are already widely used and will remain even if the Scope RFC passes, at least for backward compatibility. The two proposals are complementary. If both are accepted, the parts touching the superglobals and the session would need to work together, but nothing conflicts. Best On Thu, Oct 29, 2026 at 7:04 PM Pierre <[email protected]> wrote: > > Le 29/10/2026 à 18:47, Kévin Dunglas a écrit : > > Hello internals, > > Hello, > > I see the point and I feel it's indeed at some point becomes a > requirement for long running servers, yet to be honest this not my area > of expertise, but shouldn't the need be covered by the Scope RFC > https://wiki.php.net/rfc/scope ? > > The chosen path is different, but the goal seems to be the same in the end. > > Regards, > > Pierre
