From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24489 invoked by alias); 22 Apr 2005 08:16:53 -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 24401 invoked from network); 22 Apr 2005 08:16:39 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 22 Apr 2005 08:16:39 -0000 Received: from zaretski (IGLD-80-230-73-48.inter.net.il [80.230.73.48]) by romy.inter.net.il (MOS 3.5.6-GR) with ESMTP id BBA75945 (AUTH halo1); Fri, 22 Apr 2005 11:15:04 +0300 (IDT) Date: Fri, 22 Apr 2005 08:16:00 -0000 From: "Eli Zaretskii" To: Eli Zaretskii Message-ID: <01c54713$Blat.v2.4$5d0b4ea0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: Mark Mitchell , gdb-patches@sources.redhat.com In-reply-to: <20050421205617.GA13146@nevyn.them.org> (message from Daniel Jacobowitz on Thu, 21 Apr 2005 16:56:17 -0400) Subject: Re: PATCH: Support Windows in event-loop.c Reply-to: Eli Zaretskii 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> X-SW-Source: 2005-04/txt/msg00274.txt.bz2 > Date: Thu, 21 Apr 2005 16:56:17 -0400 > From: Daniel Jacobowitz > Cc: Mark Mitchell , gdb-patches@sources.redhat.com > > > 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'm now sorry that I used the word "misfeature" because it drew your attention away from the real objection. But since you asked: the misfeature here is that `select' works only on sockets. > - I don't think that answering your objection with an autoconf test for > WaitForMultipleObjects would make you any happier. Would it? No. The real issue is that WIN32API is an alias for _WIN32 and its ilk, something we spent some time weeding out several months ago; and that the code inside the ifdef calls WaitForMultipleObjects, which is a Windows-specific function not standardized anywhere else. > 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? The difference is that `select' and `poll' are both Posix functions, while WaitForMultipleObjects is MS-Windows specific.