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/