From: Brent Roman <brent@...>
Date: 2004-12-27T10:56:23+09:00
Subject: Re: [PATCH] Long-Standing Bug in the Readline extension

Hi,

>>> ...  So, now we have a thread becoming "critical" 
>>> asynchronously.  This leads to some very weird lockups -- some of which 
>>> have been reported on this mailing list.
> 
> 
> It would have to return immediately if rb_thread_critical is
> set.
>

I'm not sure what "it" refers to here.

If rb_thread_critical is set at the readline_getc() function
no other threads can be scheduled during the IO read.
This is usually a "bad thing", but I have used it to stop
scheduling for debugging, as in:

Thread.new  {$a=0; loop{sleep .1; $a+=1}}; sleep 1; 
Thread.critical=true; breakpoint

The "new" thread will pause while processing the breakpoint in irb.
It works as expected with the patches I just submitted
ruby-talk "Fixes for rb_thread_critical bugs"

So, I think that rb_thread_critical should be not be affected by
readline.  It's up to the caller to maintain it.


> 
>>> ...
>>> We redefine the function that GNU readline uses to read the input stream
>>> to be one based on Ruby's IO#sysread and let Ruby's own IO class
>>> deal with all its threading nastyness.
> 
> 
> Do you mean to set it to rl_getc_function?
> 

Yes.  Good catch.

There is one line inserted near the end of Init_readline():

...
     rl_attempted_completion_function
	= (CPPFunction *) readline_attempted_completion_function;
     rl_getc_function = readline_getc;  //this is the rl_getc_function
     rl_clear_signals();
}

My original patch missed this. Sorry.

-- 
  Brent Roman