normal	2018-09-13 10:43:03 +0900 (Thu, 13 Sep 2018)

  New Revision: 64707

  https://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revision&revision=64707

  Log:
    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).

  Modified files:
    trunk/thread.c
Index: thread.c
===================================================================
--- thread.c	(revision 64706)
+++ thread.c	(revision 64707)
@@ -4363,6 +4363,10 @@ rb_thread_atfork_internal(rb_thread_t *t https://github.com/ruby/ruby/blob/trunk/thread.c#L4363
 
     /* 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;

--
ML: ruby-changes@q...
Info: http://www.atdot.net/~ko1/quickml/