You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If `fork()` is called when having multiple threads, the child thread
only inherits the forking thread. Other threads simply vanish, stopping
anywhere it was executing without any cleaning up. As a result, when
using MMTk, the modbufs of other threads will not be flushed, and the
next nursery GC will fail to keep some root-reachable objects alive, and
the program will crash later.
This commit mitigates this problem by destroying mutators of dead
threads after forking. Concretely, the call of
`rb_mmtk_destroy_mutator` is moved into `thread_cleanup_func` which is
called not only when the thread exits normally, but also after forking
to clean up dead threads. That ensures the modbufs are flushed.
According to the POSIX API, if `fork()` is called while there are
multiple threads, the child can only call async-signal-safe functions
until calling execve. There are test cases (such as
`test_autoload_fork`) that forks while having multiple threads, and
there may be real-world applications doing so (see
https://bugs.ruby-lang.org/issues/14634). They are all unsafe according
to POSIX. So this commit only mitigates the problem, and programs that
fork while having multiple threads are still technically incorrect.
Fixes: #83
0 commit comments