From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28165 invoked by alias); 21 Apr 2005 20:56:24 -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 28149 invoked from network); 21 Apr 2005 20:56:19 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 21 Apr 2005 20:56:19 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DOiif-0003dO-CK; Thu, 21 Apr 2005 16:56:17 -0400 Date: Thu, 21 Apr 2005 20:56:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Mark Mitchell , gdb-patches@sources.redhat.com Subject: Re: PATCH: Support Windows in event-loop.c Message-ID: <20050421205617.GA13146@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Mark Mitchell , gdb-patches@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c546b0$Blat.v2.4$c193bb40@zahav.net.il> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-04/txt/msg00260.txt.bz2 On Thu, Apr 21, 2005 at 11:27:59PM +0300, Eli Zaretskii wrote: > > Date: Thu, 21 Apr 2005 11:56:02 -0700 > > From: Mark Mitchell > > CC: gdb-patches@sources.redhat.com > > > > Eli Zaretskii wrote: > > > > > Is it perhaps possible to write an emulation of `select' that would > > > handle file handles as well > > > > Well, Cygwin has select, so it is *possible*. But, it's not easy, and > > it doesn't really map terribly well onto what Windows provides. > > Perhaps you could look at w32proc.c:sys_select in the Emacs > distribution, and copy its code with minimal changes. > > > As Daniel says, this is very much analogous to poll/select; different > > systems provide different low-level mechanisms for waiting for input. > > It isn't analogous: HAVE_POLL tests for a system-independent > functionality, not unlike HAVE_UNISTD_H, while USE_WIN32API tests for > an OS-specific misfeature and names an OS-specific macro. I don't follow this objection: - I don't think that we get to call OS-specific interfaces "misfeatures". - I don't think that answering your objection with an autoconf test for WaitForMultipleObjects would make you any happier. Would it? How does the fact that only Windows provides WaitForMultipleObjects make it conceptually different from the fact that a bunch of systems provide poll, and a bunch don't? Anyway, if Mark can come up with a select wrapper, then maybe we can drop the question entirely. -- Daniel Jacobowitz CodeSourcery, LLC