Date: Mon, 05 Apr 1999 13:11:53 -0700 From: Terry Lambert <terry@whistle.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Robert Watson <robert@cyrus.watson.org>, current@FreeBSD.ORG Subject: Re: aio_read Message-ID: <37091909.B0257CB7@whistle.com> References: <Pine.BSF.3.96.990405141834.22049D-100000@fledge.watson.org> <199904051834.LAA11656@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote:
> :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
>
> They do indeed point to the same file entry. Also, when
> you dup() a descriptor the two descriptors are pointing
> to the same file entry.
>
> This means that they share the same seek offset... seeking
> in one descriptor changes the seek position in the other
> descriptor and even the other descriptor in the other
> process.
>
> UNIX has been broken this way from day 1. It was a major
> design mistake.
> The only way to get your own descriptor seek offset is to
> open() the file again.
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.
I'm pretty sure Ultrix didn't have this bug, either, and it was
4.3 based.
I think it's an artifact of the way the struct file is used
on a list to create the system open file table in BSD 4.4 based
systems (I checked BSDI; it has the bug).
-- Terry Lambert
-- Whistle Communications, Inc.
-- terry@whistle.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?37091909.B0257CB7>