Re: PATCH: Support Windows in event-loop.c

[Daniel Jacobowitz <drow@false.org>]

On Mon, Apr 25, 2005 at 07:59:34AM -0700, Mark Mitchell wrote:
> Christopher Faylor wrote:
> 
> >Ok...  So, is it acceptable to include a console-only implementation in
> >event-loop.c?  I would think that it wasn't.
> >
> >That seems to suggest that some kind of generic select or poll
> >implementation needs to be developed, probably using threads.
> 
> The second part of my claim seems to have gotten lost.  In particular, 
> *at present* the only handle is the console, so WaitForMultipleObjects 
> works fine.

Can you provide some evidence for this?  I don't think it's true, as I
said in my earlier message.  The current GDB seems to use it for both
Windows serial ports and for the MI console, which is likely to be a
pipe rather than a true console.

> In future, there may be other handles; my plan was that for 
> any handle for which WaitForMultipleObjects did not work directly, we 
> would create an Event, and a thread that wait for the appropriate thing 
> to happen and signal the Event.  Since WaitForMultipleObjects works with 
> Events, that would still be the right primitive to actually detect what 
> happened.
> 
> All that would need to change relative to the current code would be to 
> create/destroy the threads as necessary.  So, the current implementation 
> is only console-only in that some details haven't been added, not in 
> that it's hardwired in some permanent way to consoles.
> 
> Does that seem like a workable plan to you?

I don't think we should add something this limited.

-- 
Daniel Jacobowitz
CodeSourcery, LLC