ruby-changes:53574
From: k0kubun <ko1@a...>
Date: Sun, 18 Nov 2018 22:32:56 +0900 (JST)
Subject: [ruby-changes:53574] k0kubun:r65790 (trunk): mjit.c: fix deadlock introduced by r65785
k0kubun 2018-11-18 22:32:49 +0900 (Sun, 18 Nov 2018) New Revision: 65790 https://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revision&revision=65790 Log: mjit.c: fix deadlock introduced by r65785 in mjit_pause() fired by before_fork_ruby(). When calling RUBY_VM_CHECK_INTS() in mjit_pause()'s loop, other threads may call start_worker() which sets `stop_worker_p = FALSE` and it could wait for MJIT worker stop forever even while `stop_worker_p` is FALSE. http://ci.rvm.jp/results/trunk-mjit@silicon-docker/1466333 https://gist.github.com/ko1/a57ef1a03e1c7cfd22f1495e0864b63d http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/1466335 https://gist.github.com/ko1/96e867e36e6b75559b3d926f8c0bdaeb https://app.wercker.com/ruby/ruby/runs/mjit-test1/5bf1221c183106002855989c?step=5bf1225987436a0006192c31 Modified files: trunk/mjit.c Index: mjit.c =================================================================== --- mjit.c (revision 65789) +++ mjit.c (revision 65790) @@ -681,10 +681,10 @@ stop_worker(void) https://github.com/ruby/ruby/blob/trunk/mjit.c#L681 { rb_execution_context_t *ec = GET_EC(); - stop_worker_p = TRUE; while (!worker_stopped) { verbose(3, "Sending cancel signal to worker"); CRITICAL_SECTION_START(3, "in stop_worker"); + stop_worker_p = TRUE; /* Setting this inside loop because RUBY_VM_CHECK_INTS may make this FALSE. */ rb_native_cond_broadcast(&mjit_worker_wakeup); CRITICAL_SECTION_FINISH(3, "in stop_worker"); RUBY_VM_CHECK_INTS(ec); -- ML: ruby-changes@q... Info: http://www.atdot.net/~ko1/quickml/