https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112018-08-18T07:51:00ZRuby Issue Tracking SystemRuby master - Feature #15002: [PATCH] thread.c (sleep_*): reduce the effect of spurious interruptshttps://bugs.ruby-lang.org/issues/15002?journal_id=735942018-08-18T07:51:00Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul><li><strong>Assignee</strong> changed from <i>k0kubun (Takashi Kokubun)</i> to <i>normalperson (Eric Wong)</i></li></ul><p>Thanks to deal with it. Actually test-all with --jit-wait is running successfully on my Wercker CI and ko1's trunk-mjit-wait for now <a href="http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker" class="external">http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker</a>, but as long as it passes the tests on your environment, it looks good to merge the change to deal with the spurious interrupts by SIGCHLD from MJIT.</p>
<blockquote>
<p>Haven't investigated (I think k0kubun would know better)</p>
</blockquote>
<p>I haven't investigated yet either.</p> Ruby master - Feature #15002: [PATCH] thread.c (sleep_*): reduce the effect of spurious interruptshttps://bugs.ruby-lang.org/issues/15002?journal_id=735962018-08-18T09:07:42Znormalperson (Eric Wong)normalperson@yhbt.net
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>Applied in changeset trunk|r64444.</p>
<hr>
<p>thread.c (sleep_*): reduce the effect of spurious interrupts</p>
<p>Spurious interrupts from SIGCHLD cause Mutex#sleep (via<br>
ConditionVariable#wait) to return early and breaks some use<br>
cases. Since these are outside the programs's control with<br>
MJIT, we will only consider pending interrupts (e.g. those<br>
from Thread#run) and signals which cause a Ruby-level Signal.trap<br>
handler to fire as "spurious" wakeups.</p>
<p><a href="/issues/15002">[ruby-core:88537]</a> [Feature <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: [PATCH] thread.c (sleep_*): reduce the effect of spurious interrupts (Closed)" href="https://bugs.ruby-lang.org/issues/15002">#15002</a>]</p> Ruby master - Feature #15002: [PATCH] thread.c (sleep_*): reduce the effect of spurious interruptshttps://bugs.ruby-lang.org/issues/15002?journal_id=735972018-08-18T09:22:39Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p><a href="mailto:takashikkbn@gmail.com" class="email">takashikkbn@gmail.com</a> wrote:</p>
<blockquote>
<p>Thanks to deal with it. Actually test-all with --jit-wait is<br>
running successfully on my Wercker CI and ko1's<br>
trunk-mjit-wait for now<br>
<a href="http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker" class="external">http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker</a>, but<br>
as long as it passes the tests on your environment, it looks<br>
good to merge the change to deal with the spurious interrupts<br>
by SIGCHLD from MJIT.</p>
</blockquote>
<p>OK, r64444 is committed. It should fix spurious wakeups from<br>
the new ConditionVariable#wait specs</p>
<blockquote>
<blockquote>
<p>TestThreadQueue#test_queue_close_multi_multi [/ruby/test/ruby/test_thread_queue.rb:526]:<br>
no threads running</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>TestIO#test_recycled_fd_close [/ruby/test/ruby/test_io.rb:3804]:<br>
Expected /stream closed/ to match "closed stream".</p>
</blockquote>
</blockquote>
<p>So you guys don't see these two failures under CI?<br>
I got them every time...</p>
<blockquote>
<blockquote>
<ol start="3">
<li>Failure:<br>
TestRubyOptimization#test_tailcall_condition_block [/ruby/test/ruby/test_optimization.rb:439]:<br>
<a href="/issues/12905">[ruby-core:78015]</a> [Bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: tailcall_optimization not working as expected under certain condition order (Closed)" href="https://bugs.ruby-lang.org/issues/12905">#12905</a>]: 10079 / 20158 stack levels.<br>
Exception raised:<br>
<#<SystemStackError: stack level too deep>>.</li>
</ol>
</blockquote>
</blockquote>
<p>This one might be sporadic, I don't think I saw it every time.</p>