From owner-freebsd-current Mon Apr 5 11:28:17 1999 Delivered-To: freebsd-current@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 8D138154BA for ; Mon, 5 Apr 1999 11:28:11 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id OAA22574; Mon, 5 Apr 1999 14:26:13 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 5 Apr 1999 14:26:12 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Terry Lambert Cc: current@freebsd.org Subject: Re: aio_read In-Reply-To: <3708F93A.B2810187@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 5 Apr 1999, Terry Lambert wrote: > > What I would like to do is have a child process read > > from an inherited file descriptor without affecting the > > parent process's access to the descriptor (for example, > > the offset it reads from using a normal read() or readv()). > > This should be the way it works anyway. The offset is an > artifact of the struct file, not the vnode, and a child > process inheriting a descriptor does so by making a copy > of the parent's open file table into its own open file > table -- and thus the child gets its own struct file that > points to the vnode, and thus a seperate "current offset". This was not my impression; I thought that children had their own descriptor entries on a per-process basis, but that they all pointed to the same open file entry when inherited. I was contemplating adding a modified dup call to allow the duplication of an open file entry to add the behavior you describe, as that is actually the behavior I want. The BSD4.4 book, anyway, fairly clearly states that the behavior is a shared file offset per open file entry, and multiple open file entries pointing to a vnode. (page 205, and better yet, p207 paragraph 3). In some ways this is behavior is nice (multiple processes round-robining on data from a file, for example, or writing to a file, and in particular compatible socket-like or pipe-like behavior), in some ways it is not (desire to have an independent child). > An exception to this would be where the parent and child > share kernel structures as a result of an rfork() without > the RFFDG flag set. > > > I address this to you because you seem to be listed in the > > man page as the author of the man page (although it looks > > like John Dyson has the copyright on the source code?) > > John did the code. I did the man page because I wanted to > use it with some test code, but there wasn't a man page. 8-). Sounds good to me; I'm all for documentation. We seem to also need an aio_write page, and an aio_cancel page that documents its brokedness, etc. Maybe I'll stick them together once I finish with this project. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message