From: Jakub Travnik <j.travnik@...>
Date: 2001-11-26T05:04:53+09:00
Subject: [ruby-talk:26464] Re: [PATCH] Re: BUG in select

Yukihiro Matsumoto wrote:

> Hi,
> 
> In message "[ruby-talk:26370] [PATCH] Re: BUG in select"
>     on 01/11/25, Jakub Travnik <j.travnik@sh.cvut.cz> writes:
> 
> |Problem description:
> 
> I understand the problem.  But I'd rather modify rb_thread_select()
> (and rb_thread_schedule()) to make it more compatible to select(2).
> Do you have any suggestion?  I will work on it anyway.

I wanted a simple patch. I have done it.


Certainly a case where n == 0 in eval.c in rb_thread_schedule()
line n=select(...) should be handled specially. (only n>0 and n<0
are handled now)

I tried to fix it there first but failed.
But I was unable to distinguish two situations:
in both select return n==0

1,
thread that called ruby's select([f1,f2],[],[],nil), and none
decriptors are ready and another thread waken up from sleep thus
real kernel sleep exited due to timeout.
Thread descriptor set should not be modified and thread should
sleep more.

2,
thread have pending data, select retured because on pending data
a timeout is set to zero.
Thread descriptor set should be cleared and thread awaken.


The pending flag is local to rb_f_select in io.c,
to solve problem elesewhere that in rb_f_select,
pending flag have to be stored in thread structure
so it can be tested to distinguish situations above in
rb_thread_schedule.

I just want simple patch, so I patched it in rb_f_select.

Oh, maybe I'm wrong, let me know it then :-).


Jakub Travnik
jabber://jtra@jabber.com
ICQ: 66770334 (deprecated)