[ruby-core:39661] Re: [Ruby 1.9 - Bug #5343] Unexpected blocking behavior when interrupt Socket#accept

(2011/09/21 9:38), Tomoyuki Chikanaga wrote:
>>  Could you commit it?  Maybe 1.9.3 also needs this patch.  But I'm not
>>  sure how to commit frozen 1.9.3 branch.
> I'd be happy to commit it. I'll check in it to trunk and create a backport request ticket.

Thanks.

> BTW, let me summarize the reason why this patch works fine. If I misunderstand, please point out.
> When interrupt other thread (cf. by Thread#kill, Thread#raise) in blocking region, unblocking function (ubf) is called to interrupt blocking system call like select/ppoll etc...
> The default ubf (ubf_select)

No.  ubf_select is not a default one.  ubf_select is only for canceling
select() blocking.  If you use it for other process, it may be a bug.

> call pthread_kill() to send SIGVTALRM to interrupted thread.
> But There's race condition.
> If interrupted thread was just released GVL and received SIGVTALRM
> before entering blocking systemcall, signal was lost.
> To cover this race condition, ubf_select() also call
> add_signal_thread_list() to register "signal thread list".
> Timer thread periodically send SIGVTALRM to threads in signal thread
> list.
> Recently timer thread is suspended when there's no more than one
> runnable thread. So when interrupt other thread and register to
> signal thread list, you should activate timer thread to
> polling-mode.

Yes, absolutely.

-- 
// SASADA Koichi at atdot dot net