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 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