Re: RFA: Various Windows (mingw32) additions, mostly relating to select or serial ports

[Ian Lance Taylor <ian@airs.com>]

Daniel Jacobowitz <drow@false.org> writes:

> On Sat, Feb 04, 2006 at 04:01:07PM -0800, Ian Lance Taylor wrote:
> > Well, OK, let's try this.  Create a new pipe.  Create yet another new
> > thread which reads from the original pipe and writes to the new pipe.
> > Freopen the new pipe onto stdin.  When the new thread writes to the
> > new pipe, it signals the event loop once, and then waits.  When the
> > event loop gets the signal, it indicates that it is OK to read from
> > stdin, the new pipe.  When you reenter the event loop, it signals the
> > new thread to tell it that it is interested in more data and more
> > signals.
> 
> I'm not convinced this would work.  Remember, not only do we read from
> this pipe just about everywhere, a lot of the time we don't pass
> through the event loop.  We'd have to have a thread which did blocking
> reads from the original pipe, wrote that data straight through to a new
> pipe, and signalled an event whenever it performed a write.  Not only
> would that be tricky to get right, but we've also traded off a thread
> when selecting for a thread all the time.

I guess I had assumed that you were going to have a thread around all
the time anyhow.  Is creating a thread on Windows so cheap that one
can do it every time gdb calls select?

I also don't know whether it would work.

> Do you think the 10ms poll is sufficiently nasty to justify pursuing
> this?  I suppose I could be convinced to give it another try...

I think the 10ms poll is pretty nasty, both because polling is nasty
in general and because it introduces a delay when using gdb in a
script.  But, hey, it's only Windows, so there is certainly a limit to
how much I care.

Ian