From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5377 invoked by alias); 25 Apr 2005 14:59:52 -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 5221 invoked from network); 25 Apr 2005 14:59:43 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 25 Apr 2005 14:59:43 -0000 Received: (qmail 30955 invoked from network); 25 Apr 2005 14:59:42 -0000 Received: from localhost (HELO ?192.168.0.3?) (mitchell@127.0.0.1) by mail.codesourcery.com with SMTP; 25 Apr 2005 14:59:42 -0000 Message-ID: <426D05D6.8010903@codesourcery.com> Date: Mon, 25 Apr 2005 14:59:00 -0000 From: Mark Mitchell Organization: CodeSourcery, LLC User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Christopher Faylor CC: gdb-patches@sources.redhat.com Subject: Re: PATCH: Support Windows in event-loop.c References: <200504210549.j3L5n2nP027728@sirius.codesourcery.com> <01c546a1$Blat.v2.4$e03250c0@zahav.net.il> <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> In-Reply-To: <20050425145023.GD6543@trixie.casa.cgf.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-04/txt/msg00307.txt.bz2 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. 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? -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304