From: Aliaksey Kandratsenka Date: 2010-01-27T07:28:58+09:00 Subject: [ruby-core:27865] [Bug #2564] [patch] re-initialize timer_thread_{lock,cond} after fork Issue #2564 has been updated by Aliaksey Kandratsenka. Yes I can. But I'd like to avoid doing that. Reliable reproduction of such tiny races is not trivial. I have better ways to spend my time. Isn't this patch trivial ? Your're running timer thread that sleeps most of the time with timer_thread_lock unlocked. But periodically it wakes up and runs timer_thread_function. It does it with timer_thread_lock locked. This is 100% ok. This allows you to reliably send 'please-die' signal to this thread (in native_stop_timer_thread). (I would do it without cleanup at all. It's not very useful after all. But that's your code.) When some thread does fork timer_thread_lock will by unlocked most of the time, just because this thread sleeps most of the time. But it's possible to fork in a time when this lock is taken or is in transition to taken state. When this happens new process will simply stall trying to take this lock in rb_thread_create_timer_thread. Because this lock and associated condition is never accessed before rb_thread_create_timer_thread is called I propose to initialize both of them just before forking-off timer thread. This way original or forked process will always start with correct state of them. Fancy locking & signaling in timer thread startup code can be removed too, but that's another story. It's not bug at all. ---------------------------------------- http://redmine.ruby-lang.org/issues/show/2564 ---------------------------------------- http://redmine.ruby-lang.org