[#6660] Ruby on Neko ? — Nicolas Cannasse <ncannasse@...>

Hi folks,

14 messages 2005/11/19

[#6672] testing for hardlink with "test(?-, ...)" flawed on Windows — noreply@...

Bugs item #2858, was opened at 2005-11-20 16:35

13 messages 2005/11/20

[#6684] semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...>

Hi all,

81 messages 2005/11/21
[#6685] Re: semenatics of if/unless/while statement modifiers — Mauricio Fern疣dez <mfp@...> 2005/11/22

On Tue, Nov 22, 2005 at 08:22:59AM +0900, Stefan Kaes wrote:

[#6686] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

Mauricio Fern疣dez wrote:

[#6687] Re: semenatics of if/unless/while statement modifiers — Eric Hodel <drbrain@...7.net> 2005/11/22

On Nov 21, 2005, at 4:37 PM, Stefan Kaes wrote:

[#6689] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

Eric Hodel wrote:

[#6693] Re: semenatics of if/unless/while statement modifiers — Yukihiro Matsumoto <matz@...> 2005/11/22

Hi,

[#6695] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

Yukihiro Matsumoto wrote:

[#6718] Re: semenatics of if/unless/while statement modifiers — mathew <meta@...> 2005/11/22

[#6722] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

mathew wrote:

[#6707] Re: semenatics of if/unless/while statement modifiers — "David A. Black" <dblack@...> 2005/11/22

Hi --

[#6708] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

David A. Black wrote:

[#6714] Re: semenatics of if/unless/while statement modifiers — "David A. Black" <dblack@...> 2005/11/22

Hi --

[#6717] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

David A. Black wrote:

[#6798] ruby 1.8.4 preview2 — Yukihiro Matsumoto <matz@...>

Hi,

37 messages 2005/11/30

Re: [PATCH] win32/win32.c rb_w32_select patch for polling stdin

From: mmiller@...
Date: 2005-11-04 14:54:44 UTC
List: ruby-core #6570
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

In This Thread

Prev Next