This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA: Various Windows (mingw32) additions, mostly relating to select or serial ports
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