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

["Eli Zaretskii" <eliz at gnu dot org>]

> Date: Mon, 25 Apr 2005 11:04:22 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Christopher Faylor <me@cgf.cx>, gdb-patches@sources.redhat.com
> 
> > 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.

If console handles is the only type that can currently end up in
`select', I don't see why shouldn't we add such an emulation, however
limited.  It sounds like, according to everybody who participated in
this thread, any more able emulation is going to be much more complex,
and some of them even involve Mark K.'s dead body.  It doesn't seem
right to me to reject the patch because of theoretical deficiencies.

The code that got committed was virtually the same one suggested
originally, only in slightly different wrapping.