Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Who should close the file descriptor?
Message-ID: <10325@dog.ee.lbl.gov>
Date: 26 Feb 91 21:55:50 GMT
References: <27C4E07F.6689@maccs.dcss.mcmaster.ca> <2171@cs.rit.edu> <1020@uncw.UUCP>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 25
X-Local-Date: Tue, 26 Feb 91 13:55:50 PST

>>In article <27C4E07F.6689@maccs.dcss.mcmaster.ca>
>>ce3wa3bh@maccs.dcss.mcmaster.ca (Eric Ho) writes:
>>>In my progam, two process are spawned, ... pipe ...

>In article <2171@cs.rit.edu> dxl2585@cs.rit.edu (Derek X Lee-Wo) writes:
>>When the child process is spawned, it inherits an identical set of file
>>descriptors as the parent. 

In article <1020@uncw.UUCP> session@uncw.UUCP (Zack C. Sessions) writes:
>This actually is machine/compiler dependent. While true in UNIX, it
>is not necessarily true with all implementations of C. Not being
>familiar with ANSI C, maybe this is in ANSI C?

ANSI C (and indeed each other variation on C) has neither `processes'
nor `pipes' as a concept.  The fact that there happen to be functions
in your C library that implement both does not mean they are suitable
for comp.lang.c discussions (unless perhaps you want to propose
fork/join operations in a new variation on C).  (See, e.g., Mesa or Ada
language manuals for a description of fork/join.)

In other words, this whole topic is O/S dependent, and should move to
some O/S-specific newsgroup.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov