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.
