Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: STREAMS module / dup question
Message-ID: <1624@auspex.auspex.com>
Date: 15 May 89 19:13:48 GMT
References: <569@lehi3b15.csee.Lehigh.EDU>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 37


 >What if:
 >	1. I open a STREAM.
 >	2. I dup that stream, so now I have 2 fd's referring to
 >		that stream.
 >	3. I push a module on one of the fd's.
 >
 >Questions:
 >	1. Do both of those fd's have that module pushed on it?

Yes.  On the UNIX systems with which I'm familiar (all ultimately
AT&T-derived, e.g. V7, S3, S5, BSD, etc.):

	a "file descriptor" is a small integer that is used as an index
	into an array of pointers to "file table entries" in the kernel;

	a "file table entry" refers to an inode (or vnode, or whatever)

On those systems with streams with which I'm familiar (S5R3, and
SunOS 4.0 which uses streams code derived from S5R3), the (i|v)node
points to the stream head data structure.

When you do a "dup", those systems find an unused file descriptor and
make it point to the same file table entry as the one from which the
"dup" is being done.  This means that both file descriptors share
everything in the file table entry, and everything to which the file
table entry points; this includes the (i|v)node, and hence the stream.

>	2. What happens during a fork()?

In the aforementioned systems, when a "fork" is done, the new process
gets its own array of pointers to file table entries; this table starts
out containing the exact same set of pointers that the one in the old
process contains.  Thus, file descriptor N in the child refers to the
same file table entry as file descriptor N in the parent, and they thus
share everything in the file table entry, and everything to which it
points, including the stream.