aboutsummaryrefslogtreecommitdiffstats
path: root/thread.c
diff options
context:
space:
mode:
authornormal <normal@b2dd03c8-39d4-4d8f-98ff-823fe69b080e>2018-09-13 01:43:03 +0000
committernormal <normal@b2dd03c8-39d4-4d8f-98ff-823fe69b080e>2018-09-13 01:43:03 +0000
commit6f0fb60f36c8d0e2b94fa5dc840561c7bfd92d0d (patch)
tree444ee0748d1e2ba768e2ab028926f76cca624f5b /thread.c
parent35aa8fd004b61549180af788ad5d786c93e3a9cd (diff)
downloadruby-6f0fb60f36c8d0e2b94fa5dc840561c7bfd92d0d.tar.gz
thread.c (rb_thread_atfork): reinitialize current th->interrupt_lock
Another thread may be holding th->interrupt_lock while our current thread calls fork. Therefore we must reinitialize our own th->interrupt_lock in the child process because the owner of the lock is only in the parent. The original parent process is unaffected. We cannot destroy the lock while it has an unknown state, either, so some implementations can leak a small amount of memory, here (NPTL won't). git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64707 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Diffstat (limited to 'thread.c')
-rw-r--r--thread.c4
1 files changed, 4 insertions, 0 deletions
diff --git a/thread.c b/thread.c
index 3f5dcb4827..ccb1346487 100644
--- a/thread.c
+++ b/thread.c
@@ -4363,6 +4363,10 @@ rb_thread_atfork_internal(rb_thread_t *th, void (*atfork)(rb_thread_t *, const r
/* may be held by MJIT threads in parent */
rb_native_mutex_initialize(&vm->waitpid_lock);
+
+ /* may be held by any thread in parent */
+ rb_native_mutex_initialize(&th->interrupt_lock);
+
vm->fork_gen++;
vm->sleeper = 0;