Re: Re: Request lifecycle hooks for SAPIs that serve multiple requests per script (like FrankenPHP in worker mode)

Hi Larry, Sorry for the top post :/ We're still early in the process of Scope adoption, and Scope will have to interact with existing worker modes anyway, because their APIs are already widely used in the wild. Scope will also have to deal with what my proposal solves: letting extensions detect when the response has been sent (currently, a Scope lives as long as something references it, which can be long after the request is finished), and resetting the state tied to the request: sessions (as explained in the Scope RFC), output buffers, the URL rewriter, etc. I propose combining the two: once Scope is accepted and implemented, php_request_begin() will create a new scope, and SAPIs will get it for free. When the HTTP response is finished, SAPIs call php_request_end(), so extensions have a hook to do what they want when a request terminates, even if the Scope survives because it is still referenced. For instance, with FrankenPHP: <?php $scope = null; while (frankenphp_handle_request(function () use (&$scope) { // C function php_request_begin() has been called by FrankenPHP's SAPI: this callback runs in a new scope $scope = Scope::getCurrent(); // leaked on purpose })) { // php_request_end() called by FrankenPHP: the session is written and extensions flushed their data, even though $scope is still alive } The user-space and engine-space lifetimes stay in sync because the SAPI drives both. Both proposals work well together. It also allows continuing work on both (almost) independently and lets them ship at their own pace, regardless of the result of their respective votes.