From:	ian AT cygnus DOT com (Ian Lance Taylor)
Subject:	Re: Question
8 Apr 1998 14:09:25 -0700 :
Message-ID:	<199804082045.QAA02376.cygnus.cygwin32.developers@subrogation.cygnus.com>
References:	<01BD634F DOT AEEE7030 AT sos>
To:	sos AT buggy DOT prospect DOT com DOT ru
Cc:	cygwin32-developers AT cygnus DOT com

   From: Sergey Okhapkin <sos AT buggy DOT prospect DOT com DOT ru>
   Date: Thu, 9 Apr 1998 00:37:31 +0400

   Ian Lance Taylor wrote:
   >>    Should file descriptors other than stdin/stdout/stderr be inheritted 
   on spawn()? >>It seems to me they shouldn't...
   >
   > Why not?
   >
   > I mean, I don't see any special reason why they should be inherited,
   > but I also don't see any special reason why they shouldn't be
   > inherited.  The operation seems well defined either way.
   >

   Yes. If fds>2 will not be inheritted on spawn, it will be easy to create 
   pipelines with spawn calls. Look at pexecute.c in egcs sources for _WIN32 
   but no __CYGWIN32__ case (mingw32?). I'm not sure that gcc will work 
   properly if cpp will terminate due to some error (spawned ΣΣ1 will inherit 
   last_pipe_input and will never receive EOF!). The compilation will just 
   hangs...

I don't understand.  At a quick glance, pexecute appears to close the
descriptors correctly.  As far as I can tell, if the descriptors were
not closed, then gcc would hang whether or not cpp terminated due to
an error.  Certainly cpp doesn't close any unexpected descriptors, so
I don't see why it matters whether it dies or exits normally.

Can you describe the potential error more fully?

Ian

- Raw text -