process_wait
can hang if reusing FD in rapid succession.
#126
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.
It looks like EPoll can hang when executing
system
. Ifprocess_wait
is called in rapid succession and hits the same file descriptor, the internal state can be reused, which may assume theepoll
is currently armed when it is not, leading to a hang.IO_Event_Selector_EPoll_Waiting_register(..., 0, pidfd, ...)
epoll_ctl
ADD.epoll_wait
-> statusIO_Event_Selector_EPoll_Waiting_register(..., 0, pidfd, ...)
but we hitepoll_descriptor->registered_events == epoll_descriptor->waiting_events
branch (return).This is because the argument for
VALUE io
is 0 in both cases, so we assume the IO is the same object, and thus the registration has not changed. By providing_pid
as theio
object, we prevent this from happening. I'll think about a better solution, as this feels like a hack; we can probably clear the state afterprocess_wait
instead, on all cases, which prevents any re-use._pid
is unlikely to wrap around rapidly so the chance of hitting this bug is greatly reduced, but not zero, with the current proposed change.Fixes socketry/async#351.
Types of Changes
Contribution