From owner-freebsd-current  Tue Dec  2 10:59:01 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id KAA22856
          for current-outgoing; Tue, 2 Dec 1997 10:59:01 -0800 (PST)
          (envelope-from owner-freebsd-current)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA22833;
          Tue, 2 Dec 1997 10:58:49 -0800 (PST)
          (envelope-from toor@dyson.iquest.net)
Received: (from root@localhost)
	by dyson.iquest.net (8.8.7/8.8.8) id NAA02027;
	Tue, 2 Dec 1997 13:54:58 -0500 (EST)
	(envelope-from toor)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199712021854.NAA02027@dyson.iquest.net>
Subject: Re: FYI: usage of new AIO calls
In-Reply-To: <199712021848.LAA18076@usr04.primenet.com> from Terry Lambert at "Dec 2, 97 06:48:54 pm"
To: tlambert@primenet.com (Terry Lambert)
Date: Tue, 2 Dec 1997 13:54:58 -0500 (EST)
Cc: dyson@freebsd.org, tlambert@primenet.com, toor@dyson.iquest.net,
        current@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Terry Lambert said:
> > BTW, I also plan to implement pread/pwrite, but haven't decided to
> > implement as a kernel call, or as a section (3) subroutine. (Those
> > are less of an issue though.)
> 
> I don't think you can implement pread/pwrite as section (3) routines;
> the need for them arises from the need to pass a seek offset with
> a read or write request because you can't trust the seek+read or
> seek+write to be atomic -- so implementing them that way would
> leave a race window open.
>
Actually, I was thinking about implementing them as aio_read/aio_write, with
a aio_suspend and aio_error call.  Those would likely have no such race
conditions.  (aio_read/aio_write are atomic.)

> 
> I know that; it's just evil that the POSIX people have implemented
> before thinking.  SVR4 kernel threading was implemented without a
> great deal of thinking (the SVR4 VM architect assured me that there
> was VM support for dynamic per thread stacks, but that the SVR4
> threading implementation simply chose to ignore it in favor of
> statically allocated stacks; similar cases abound).
> 
Actually, I had thought about supporting dynamic per thread stacks, but
nothing keeps us from doing that as an *extra*.  The decision by POSIX
was probably made as a compromise.

>
> I hate the fact that it's still possible to make a non-I/O based blocking
> call (like, oh, wait3()) that doesn't result in a call conversion and
> context switch: basically, you *must* give away your quantum that you
> were promised by the scheduler in order to make this and similar
> calls.  What were they thinking?
> 
Interesting thought.


-- 
John
dyson@freebsd.org
jdyson@nc.com