Fix possible accept() race condition when multiple socket servers listen on same socket address#244
Uh oh!
There was an error while loading. Please reload this page.
Conversation
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
Multiple socket servers can listen on the same socket address (using `SO_REUSEPORT` or shared file descriptors). Accordingly, when a new connection is incoming, multiple event-loops could report the socket to be readable and try to a `accept()` an incoming connection from the same socket. This wouldn't be an issue with the underlying `accept()` system call. The first call would succeed and subsequent calls would report `EAGAIN` or `EWOULDBLOCK` for the other servers given the socket resource is in non-blocking mode. However, PHP's `stream_socket_accept()` implementation first runs a `poll()` on the socket resource before performing an `accept()`. This means multiple instances listening on the same address could end up in a race condition where some may be "stuck" in the pending `poll()`. We work around this by specifiying a `0` timeout to ensure the `poll()` doesn't block in this case. This allows all servers to either complete successfully or report an error and continue processing right away.
WyriHaximus approved these changes Aug 23, 2020
jsor approved these changes Aug 24, 2020
Sign up for freeto 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.
Multiple socket servers can listen on the same socket address (using
SO_REUSEPORTor shared file descriptors). Accordingly, when a newconnection is incoming, multiple event-loops could report the socket to
be readable and try to a
accept()an incoming connection from the samesocket.
This wouldn't be an issue with the underlying
accept()system call.The first call would succeed and subsequent calls would report
EAGAINor
EWOULDBLOCKfor the other servers given the socket resource is innon-blocking mode.
However, PHP's
stream_socket_accept()implementation first runs apoll()on the socket resource before performing anaccept(). Thismeans multiple instances listening on the same address could end up in a
race condition where some may be "stuck" in the pending
poll().See https://github.com/php/php-src/blob/91fbd12d5736b3cc9fc6bc2545e877dd65be1f6c/main/network.c#L707
We work around this by specifiying a
0timeout to ensure thepoll()doesn't block in this case. This allows all servers to either complete
successfully or report an error and continue processing right away.
Additionally, this also fixes two test failures for PHP 8. Instead of using an invalid (closed) socket server to test error reporting, we now use a socket that doesn't have a pending connection (refs #243). I'll file another PR address the last test failures on PHP 8, but this is currently blocked by #243.
Among others, this is a prerequisite for #164