From owner-freebsd-current  Mon Apr  5 13:27:45 1999
Delivered-To: freebsd-current@freebsd.org
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
	by hub.freebsd.org (Postfix) with ESMTP id 9A45315152
	for <current@FreeBSD.ORG>; Mon,  5 Apr 1999 13:27:42 -0700 (PDT)
	(envelope-from terry@whistle.com)
Received: from whistle.com (tlambert.whistle.com [207.76.205.208])
	by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id NAA74651;
	Mon, 5 Apr 1999 13:21:53 -0700 (PDT)
Message-ID: <37091909.B0257CB7@whistle.com>
Date: Mon, 05 Apr 1999 13:11:53 -0700
From: Terry Lambert <terry@whistle.com>
X-Mailer: Mozilla 4.06 [en] (Win95; I)
MIME-Version: 1.0
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Robert Watson <robert@cyrus.watson.org>, current@FreeBSD.ORG
Subject: Re: aio_read
References: <Pine.BSF.3.96.990405141834.22049D-100000@fledge.watson.org> <199904051834.LAA11656@apollo.backplane.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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