Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Apr 1999 16:33:00 -0400 (EDT)
From:      Robert Watson <robert@cyrus.watson.org>
To:        Terry Lambert <terry@whistle.com>
Cc:        Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject:   Re: aio_read
Message-ID:  <Pine.BSF.3.96.990405162819.23485A-100000@fledge.watson.org>
In-Reply-To: <37091909.B0257CB7@whistle.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 5 Apr 1999, Terry Lambert wrote:

> After you said this, I found it so hard to believe that I had
> to go look.

:-)

> All I can say is, well I'll be damned; you could knock me over
> with a feather, and that doesn't happen often.
> 
> I'm sure SVR4 and UnixWare is not like this; I had to write
> code explicitly for UnixWare, Solaris, and AIX to get, among
> other things, this type of behaviour.
> 
> Here's the comment from Solaris:
> 
> /*
>  * One file structure is allocated for each open/creat/pipe call.
>  * Main use is to hold the read/write pointer associated with
>  * each open file.
>  */
> typedef struct file {
> 
> It also credits SVr4 11.28 for file.h itself.

Solaris fork() man page reports:

SunOS 5.6 Last change: 28 Dec 1996 1
 
System Calls fork(2) 
 
          o The child process has its own copy of the parent's
            file descriptors and directory streams.  Each of the
            child's file descriptors shares a common file pointer
            with the corresponding file descriptor of the parent. 
 
Sorry :-).  Sounds like this is in fact the documented correct behavior on
all the platforms I can get to.

And HPUX:
 
      Each of the child's file descriptors shares a common open file
      description with the corresponding file descriptor of the parent. 
      This implies that changes to the file offset, file access mode, and
      file status flags of file descriptors in the parent also affect
those
      in the child, and vice-versa. 
 
 Hewlett-Packard Company            - 1 -     HP-UX Release 9.0: August
1992    


The linux fork man page doesn't discuss it, but I did note they implement
vfork() as an alias to fork(), suggesting that their fork and exec should
be less efficient than ours?


  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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990405162819.23485A-100000>