Fix #78469: fcgi_accept_request must call on_accept hook for named pipes too#4636
Closed
turchanov wants to merge 1 commit intophp:PHP-7.2from
Closed
Fix #78469: fcgi_accept_request must call on_accept hook for named pipes too#4636turchanov wants to merge 1 commit intophp:PHP-7.2from
turchanov wants to merge 1 commit intophp:PHP-7.2from
Conversation
fcgi_accept_request function is supposed to call a FastCGI implementation's on_accept hook when entering an "accepting" stage (that is right before calling "accept"). This hook implementation (fpm_request_accepting) updates a worker state to an "accepting" state which is effectively an "Idle" state, and updates counters on the scoreboard of the corresponding pool (idle++, active--). But this is not done when listening for client connections on a named pipe on Windows platform. In that case a combination of ConnectNamedPipe/WaitForSingleObject is used (to be able to catch in_shutdown as far as I understand), but it is nonetheless functionally equivalent to "accept" call. Also by not calling on_hook neither a worker's state is updated to "accepting" state nor scoreboard counters are updated.
turchanov
added a commit
to turchanov/php-src
that referenced
this pull request
Aug 28, 2019
…ter fastcgi_finish_request To retain legacy behavior I decided to add an option to control request termination logic. If request_terminate_strict is set then request will be tracked for time limits even after fastcgi_finish_request was called. This patch depends on the fix provided in BUG 78469 (otherwise php-fpm workers listening on named pipes on Windows will be erroneously terminated) (PR php#4636)
nikic
approved these changes
Aug 30, 2019
Member
|
Merged as 8f564e5 into 7.2+. Thanks! |
php-pulls
pushed a commit
that referenced
this pull request
Sep 30, 2019
…ter fastcgi_finish_request To retain legacy behavior I decided to add an option to control request termination logic. If request_terminate_timeout_track_finished is set, then request will be tracked for time limits even after fastcgi_finish_request was called. This patch depends on the fix provided in BUG 78469 (otherwise php-fpm workers listening on named pipes on Windows will be erroneously terminated) (PR #4636)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fcgi_accept_request function is supposed to call a FastCGI implementation's
on_accept hook when entering an "accepting" stage (that is right before
calling "accept"). This hook implementation (fpm_request_accepting) updates
a worker state to an "accepting" state which is effectively an "Idle" state,
and updates counters on the scoreboard of the corresponding pool (idle++,
active--).
But this is not done when listening for client connections on a named pipe on
Windows platform. In that case a combination of
ConnectNamedPipe/WaitForSingleObject is used (to be able to catch in_shutdown
as far as I understand), but it is nonetheless functionally equivalent to
"accept" call. Also by not calling on_hook neither a worker's state is updated
to "accepting" state nor scoreboard counters are updated.