Issue #5130 has been updated by Jeremy Evans.


It's been a couple of months since this issue was last updated, and about three months since this issue was last updated by a ruby committer.  Can a ruby committer look at either Eric's patch or my patch and let us know if this is an appropriate fix?  I can't think of a reason why you would want to start a thread if the interpreter is shutting down, so the patch makes sense to me.  Eric is right that this doesn't fix the race condition, but it should at least reduce the probability of it happening.

Looking at the thread log I sent earlier, the thread that starts after rb_thread_terminate_all is called calls rb_thread_schedule_limits, but gvl_yield apparently never changes the thread pointer, so it always yields to itself.

My theory is that when rb_thread_terminate_all calls terminate_i on a thread that has been created but not started, the thread never gets the terminate signal, so it continues to run indefinitely.  So I think the patch makes sense.  Alternatively thread_start_func_2 could check th->thrown_errinfo or th->status instead of GET_VM()->inhibit_thread_creation.  I haven't tried that, but it could be a more general fix.
----------------------------------------
Bug #5130: Thread.pass sticks on OpenBSD
http://redmine.ruby-lang.org/issues/5130

Author: Yui NARUSE
Status: Feedback
Priority: Normal
Assignee: Motohiro KOSAKI
Category: core
Target version: 
ruby -v: -


=begin
On OpenBSD 4.9, following script will stick.

 ./miniruby -ve'Thread.new{Thread.pass}'
=end



-- 
http://redmine.ruby-lang.org