Proof of Concept: Allow to prevent fork from happening in known fork unsafe API #10864
Conversation
This file contains 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
casperisfine
force-pushed
the
fork-lock
branch
3 times, most recently
from
cfd7fcd
to
058e40e
Compare
This comment has been minimized.
This comment has been minimized.
| @@ -498,9 +524,6 @@ rb_getaddrinfo(const char *hostp, const char *portp, const struct addrinfo *hint | |||
| errno = err; | |||
| return EAI_SYSTEM; | |||
| } | |||
| pthread_detach(th); | |||
|
|
|||
| rb_thread_call_without_gvl2(wait_getaddrinfo, arg, cancel_getaddrinfo, arg); | |||
There was a problem hiding this comment.
Was this deleted on purpose? it seems important to me! (it's the bit that actually waits on the condvar for the lookup to be done, right?)
There was a problem hiding this comment.
Nah, just a bad rebase I think, let me check.
There was a problem hiding this comment.
Ok, fixed it. It should have been replaced by fork_safe_async_getaddrinfo(arg);
…unsafe API For better of for worse, fork(2) remain the primary provider of parallelism in Ruby programs. Even though it's frowned uppon in many circles, and a lot of literature will simply state that only async-signal safe APIs are safe to use after `fork()`, in practice most APIs work well as long as you are careful about not forking while another thread is holding a pthread mutex. One of the APIs that is known cause fork safety issues is `getaddrinfo`. If you fork while another thread is inside `getaddrinfo`, a mutex may be left locked in the child, with no way to unlock it. I think we could reduce the impact of these problem by preventing in for the most notorious and common cases, by locking around `fork(2)` and known unsafe APIs with a read-write lock.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
For better of for worse, fork(2) remain the primary provider of parallelism in Ruby programs. Even though it's frowned uppon in many circles, and a lot of literature will simply state that only async-signal safe APIs are safe to use after
fork(), in practice most APIs work well as long as you are careful about not forking while another thread is holding a pthread mutex.One of the APIs that is known cause fork safety issues is
getaddrinfo. If you fork while another thread is insidegetaddrinfo, a mutex may be left locked in the child, with no way to unlock it.I think we could reduce the impact of these problem by preventing in for the most notorious and common cases, by locking around
fork(2)and known unsafe APIs with a read-write lock.FYI: @mame @beauraF