From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21146 invoked by alias); 26 Apr 2005 03:49:29 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21111 invoked from network); 26 Apr 2005 03:49:20 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 26 Apr 2005 03:49:20 -0000 Received: from zaretski (IGLD-80-230-41-251.inter.net.il [80.230.41.251]) by romy.inter.net.il (MOS 3.5.6-GR) with ESMTP id BBP35107 (AUTH halo1); Tue, 26 Apr 2005 06:49:14 +0300 (IDT) Date: Tue, 26 Apr 2005 03:49:00 -0000 From: "Eli Zaretskii" To: gdb-patches@sources.redhat.com Message-ID: <01c54a12$Blat.v2.4$dba641a0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 In-reply-to: <20050425150422.GA13753@nevyn.them.org> (message from Daniel Jacobowitz on Mon, 25 Apr 2005 11:04:22 -0400) Subject: Re: PATCH: Support Windows in event-loop.c Reply-to: Eli Zaretskii References: <4267F742.2090108@codesourcery.com> <01c546b0$Blat.v2.4$c193bb40@zahav.net.il> <20050421205617.GA13146@nevyn.them.org> <01c54713$Blat.v2.4$5d0b4ea0@zahav.net.il> <20050424221806.GA13942@nevyn.them.org> <426C3270.4050608@codesourcery.com> <20050425042414.GA7322@trixie.casa.cgf.cx> <20050425131611.GA7821@nevyn.them.org> <20050425145023.GD6543@trixie.casa.cgf.cx> <426D05D6.8010903@codesourcery.com> <20050425150422.GA13753@nevyn.them.org> X-SW-Source: 2005-04/txt/msg00336.txt.bz2 > Date: Mon, 25 Apr 2005 11:04:22 -0400 > From: Daniel Jacobowitz > Cc: Christopher Faylor , 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.