[前][次][番号順一覧][スレッド一覧]

ruby-changes:51900

From: normal <ko1@a...>
Date: Mon, 30 Jul 2018 14:51:06 +0900 (JST)
Subject: [ruby-changes:51900] normal:r64114 (trunk): thread_pthread.c (gvl_destroy): make no-op on GVL bits

normal	2018-07-30 14:51:01 +0900 (Mon, 30 Jul 2018)

  New Revision: 64114

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

  Log:
    thread_pthread.c (gvl_destroy): make no-op on GVL bits
    
    It's possible for another thread to take vm->gvl.lock
    during gvl_release at the end of thread_start_func_2
    during VM shutdown, at least.

  Modified files:
    trunk/thread_pthread.c
Index: thread_pthread.c
===================================================================
--- thread_pthread.c	(revision 64113)
+++ thread_pthread.c	(revision 64114)
@@ -208,9 +208,16 @@ gvl_init(rb_vm_t *vm) https://github.com/ruby/ruby/blob/trunk/thread_pthread.c#L208
 static void
 gvl_destroy(rb_vm_t *vm)
 {
-    rb_native_cond_destroy(&vm->gvl.switch_wait_cond);
-    rb_native_cond_destroy(&vm->gvl.switch_cond);
-    rb_native_mutex_destroy(&vm->gvl.lock);
+    /*
+     * only called once at VM shutdown (not atfork), another thread
+     * may still grab vm->gvl.lock when calling gvl_release at
+     * the end of thread_start_func_2
+     */
+    if (0) {
+        rb_native_cond_destroy(&vm->gvl.switch_wait_cond);
+        rb_native_cond_destroy(&vm->gvl.switch_cond);
+        rb_native_mutex_destroy(&vm->gvl.lock);
+    }
     clear_thread_cache_altstack();
 }
 

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

[前][次][番号順一覧][スレッド一覧]