From: Eric Wong Date: 2018-08-18T11:36:54+00:00 Subject: [ruby-core:88541] Re: [Ruby trunk Bug#14999] ConditionVariable doesn't reacquire the Mutex if Thread#kill-ed eregontp@gmail.com wrote: > What was wrong with the first patch? I still saw CI failures with it: http://ci.rvm.jp/results/trunk_gcc7@silicon-docker/1234097 In retrospect, it could've also been fixed with [Feature #15002] > It looks good from a quick glance, although indeed it doesn't deal with Mutex_m. > Maybe Thread.handle_interrupt(Object => :on_blocking) (or the equivalent in C) would help? I considered that, but the problem might stem from blocking in an unexpected place (because CV#wait is being spuriously woken). > > No good. Now testing: > > https://80x24.org/spew/20180818062657.3424-1-e@80x24.org/raw > > I don't think that's OK for semantics. > IMHO, anything in the synchronize block should hold the Mutex, otherwise we break users' assumptions. > So even if there is an exception waking ConditionVariable#wait, I believe users expect to own the Mutex during that exception, until getting out of the synchronize. > Otherwise, it's very surprising if the ensure block sometimes has, sometimes doesn't have the Mutex and so can't reliably modify data structures protected by the Mutex. > I also believe this was the behavior on Ruby 2.5 and older, but I might be wrong (at least I couldn't observe the spec to fail in thousands of tries). OK, I didn't consider the ensure case. So maybe you can revert r64441 (I'm going AFK for a while), because there's a chance r64444 also fixed the issue. Last alert email I got was 2018-08-18 08:59Z, so it's been a while since I got an alert (this is from ko1's ruby-alerts list, I don't know if you're on it). Unsubscribe: