On Fri, Nov 04, 2005 at 06:46:52PM +0900, nobuyoshi nakada wrote:
> Hi,
> 
> At Fri, 4 Nov 2005 15:56:34 +0900,
> mmiller / hick.org wrote in [ruby-core:06565]:
> > Recently I encountered a problem that I think others have experienced
> > before that has to do with using gets on standard input and its side
> > effect of blocking all other ruby threads on win32.  The problem has to
> > do with the fact that the existing code will simply indicate that there
> > is data on any non-socket file handle that is passed to select (which
> > includes stdin).  This leads to a blocking call being made to read (via
> > getc) that prevents other ruby threads from running until data has been
> > written to the console.  To help address this problem, I'm submitting a
> > patch that seems to address the issue, though perhaps there is a better
> > way to go about integrating it (I'll leave that up to the developers).
> 
> It should have been improved with 1.9, I guess.

I looked around on the site and may have missed it, but is there a
scheduled release time for 1.9?  Is this improved due to changes in the
win32 select code (I looked at CVS last night after submitting this
patch and noticed there have been a number of changes), or is it more
related to the switch to native threading?  On a side note, the switch
to using native threading is great news.

I think my biggest problem is that I've been working on a project that
makes extensive use of ruby threads at the moment and this issue will
block me from being able to deploy it on win32 without using a custom
patch like the one I submitted (and thus a custom interpreter) for the
1.8.x series.

> > +            if (WaitForSingleObjectEx(GetStdHandle(STD_INPUT_HANDLE),
> > +                    0, TRUE) == WAIT_OBJECT_0)
> > +                stdin_data = 1;
> 
> It is signaled even if a mouse event arrived, e.g., just moving
> mouse.

This is true.  One slightly hackish way that this could be improved upon
would be to use GetNumberOfConsoleInputEvents / PeekConsoleInput to
determine if the only events in the queue are non-keyboard events
(window resize, focus, mouse, etc).  These events could be discarded if
ruby doesn't do anything with them under normal circumstances, though
this may be risky if custom applications interact with console functions
directly via dl.  Hopefully there is a better way to do this that I'm
not aware of (perhaps a pipe would work?).

Matt