Skip to content

Allow waitpid(-1) to be woken if a waitpid(pid) call is pending (3.1 backport) #8246

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

KJTsanaktsidis
Copy link
Contributor

If two threads are running, with one calling waitpid(-1), and another calling waitpid($some_pid), and then $some_other_pid exits, we would expect the waitpid(-1) call to retrieve that exit status; however, it cannot actually do so until $some_pid also exits.

This patch fixes the issue by unconditionally checking for pending process group waits on SIGCHLD, and then allowing pending pid-only waits to "steal" the notification.

https://bugs.ruby-lang.org/issues/19837

[Fixes #19387]

@KJTsanaktsidis KJTsanaktsidis changed the title Allow waitpid(-1) to be woken if a waitpid(pid) call is pending Allow waitpid(-1) to be woken if a waitpid(pid) call is pending (3.1 backport) Aug 18, 2023
@KJTsanaktsidis KJTsanaktsidis force-pushed the ktsanaktsidis/backport_waitpid_ruby_3_1 branch from 3ec34fa to 601dc04 Compare August 18, 2023 14:25
@hsbt hsbt added the Backport label Aug 24, 2023
If two threads are running, with one calling waitpid(-1), and another
calling waitpid($some_pid), and then $some_other_pid exits, we would
expect the waitpid(-1) call to retrieve that exit status; however, it
cannot actually do so until $some_pid _also_ exits.

This patch fixes the issue by unconditionally checking for pending
process group waits on SIGCHLD, and then allowing pending pid-only waits
to "steal" the notification.

[Fixes #19387]
@KJTsanaktsidis KJTsanaktsidis force-pushed the ktsanaktsidis/backport_waitpid_ruby_3_1 branch from 601dc04 to e4deff7 Compare August 30, 2023 18:36
@KJTsanaktsidis
Copy link
Contributor Author

Apologies @hsbt - I had messed up my merging and a previous version of this PR failed the test I added. I've fixed that now. The current CI failures all seem to be build infrastructure issues...

@unak unak merged commit c08fdc6 into ruby:ruby_3_1 Sep 5, 2023
@stanhu
Copy link
Contributor

stanhu commented Jan 13, 2024

@unak Do you know if there is a timeline for another Ruby 3.1 or 3.2 release? We hit this bug in production (puma/puma#3313), and it caused some significant performance issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants