From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6463 invoked by alias); 12 Apr 2007 15:12:33 -0000 Received: (qmail 6452 invoked by uid 22791); 12 Apr 2007 15:12:32 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 12 Apr 2007 16:12:28 +0100 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id A164D4B267; Thu, 12 Apr 2007 10:12:26 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id 7CA144B262; Thu, 12 Apr 2007 10:12:24 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.63) (envelope-from ) id 1Hc0yE-0000JA-IB; Thu, 12 Apr 2007 11:12:22 -0400 Date: Thu, 12 Apr 2007 15:12:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb@sourceware.org Subject: Re: [mingw32] stdin redirection Message-ID: <20070412151221.GA856@caradoc.them.org> Mail-Followup-To: Joel Brobecker , gdb@sourceware.org References: <20070411134219.GA33609@adacore.com> <20070411144451.GA21140@caradoc.them.org> <20070411145104.GE58502@adacore.com> <20070411151234.GA22185@caradoc.them.org> <20070412145818.GG3886@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070412145818.GG3886@adacore.com> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-04/txt/msg00071.txt.bz2 On Thu, Apr 12, 2007 at 04:58:18PM +0200, Joel Brobecker wrote: > > Otherwise, see the call site, where no handle is provided. > > So we must be falling back to the file handle (mingw-hdep.c). > > Maybe we need to do something different to simulate select on a file. > > Sorry, we're not sure what you mean. Could you elaborate? For a pipe, we use PeekNamedPipe to figure out how many bytes are available in the pipe and whether select on the pipe should return. For a file, we use the fallback case: we pass the file's HANDLE to WaitForMultipleObjects. What does a file HANDLE do when waited on? Maybe it's not the useful behavior. > If we could find a way to replace the current implementation of > fd_is_pipe into something that avoids using any of the pipe functions, > then that would probably solve our problem. Unfortunately, despite > our intensive search of MSDN, nothing turned up. To the best of my knowledge there is no way. > However, the little hack we have been using in fd_is_pipe (basically > always return false) seems to indicate that it is OK to treat the > case of pipes and files the same way. I don't believe this. When you wait for a pipe's handle, it returns that the handle is signalling if it is valid to connect to the pipe. This condition has nothing to do with whether we can read from the pipe. Are you sure that you tested any case in which fd_is_pipe returned true? I don't remember exactly what the failure mode was, but it's not immediately obvious; we decide there is data available, try to read it, and either block in read or fail to read unexpectedly. So we run around in readline when we should be sleeping. Remote debugging is most likely to show this problem, especially "target remote |" if you have any stubs that talk on stdio. -- Daniel Jacobowitz CodeSourcery