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.
Related issues
Feature #20590: Ensure `fork` isn't called when `raddrinfo`'s background thread is in `getaddrinfo`
Added by byroot (Jean Boussier) about 1 year ago
Proof of Concept: Allow to prevent fork from happening in known fork unsafe API
[Feature #20590]
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 practicemost 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 mutexmay 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.