From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10528 invoked by alias); 25 Apr 2005 15:04:32 -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 10443 invoked from network); 25 Apr 2005 15:04:25 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 25 Apr 2005 15:04:25 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DQ58I-0003eg-Ef; Mon, 25 Apr 2005 11:04:22 -0400 Date: Mon, 25 Apr 2005 15:04:00 -0000 From: Daniel Jacobowitz To: Mark Mitchell Cc: Christopher Faylor , gdb-patches@sources.redhat.com Subject: Re: PATCH: Support Windows in event-loop.c Message-ID: <20050425150422.GA13753@nevyn.them.org> Mail-Followup-To: Mark Mitchell , Christopher Faylor , gdb-patches@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426D05D6.8010903@codesourcery.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-04/txt/msg00308.txt.bz2 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