122 lines
4.3 KiB
Plaintext
122 lines
4.3 KiB
Plaintext
From fork-admin@xent.com Sat Sep 7 21:52:42 2002
|
|
Return-Path: <fork-admin@xent.com>
|
|
Delivered-To: yyyy@localhost.spamassassin.taint.org
|
|
Received: from localhost (jalapeno [127.0.0.1])
|
|
by jmason.org (Postfix) with ESMTP id 8281416F18
|
|
for <jm@localhost>; Sat, 7 Sep 2002 21:52:19 +0100 (IST)
|
|
Received: from jalapeno [127.0.0.1]
|
|
by localhost with IMAP (fetchmail-5.9.0)
|
|
for jm@localhost (single-drop); Sat, 07 Sep 2002 21:52:19 +0100 (IST)
|
|
Received: from xent.com ([64.161.22.236]) by dogma.slashnull.org
|
|
(8.11.6/8.11.6) with ESMTP id g86KLLC22654 for <jm@jmason.org>;
|
|
Fri, 6 Sep 2002 21:21:21 +0100
|
|
Received: from lair.xent.com (localhost [127.0.0.1]) by xent.com (Postfix)
|
|
with ESMTP id 21833294287; Fri, 6 Sep 2002 13:16:03 -0700 (PDT)
|
|
Delivered-To: fork@spamassassin.taint.org
|
|
Received: from localhost.localdomain (pm0-8.sba1.netlojix.net
|
|
[207.71.218.8]) by xent.com (Postfix) with ESMTP id 55EC929427E for
|
|
<fork@xent.com>; Fri, 6 Sep 2002 13:15:34 -0700 (PDT)
|
|
Received: (from dave@localhost) by maltesecat (8.8.7/8.8.7a) id NAA21491;
|
|
Fri, 6 Sep 2002 13:25:33 -0700
|
|
Message-Id: <200209062025.NAA21491@maltesecat>
|
|
To: fork@spamassassin.taint.org
|
|
Subject: Re: asynchronous I/O (was Re: Gasp!)
|
|
In-Reply-To: Message from fork-request@xent.com of
|
|
"Fri, 06 Sep 2002 06:25:37 PDT."
|
|
<20020906132537.6311.58517.Mailman@lair.xent.com>
|
|
From: Dave Long <dl@silcom.com>
|
|
Sender: fork-admin@xent.com
|
|
Errors-To: fork-admin@xent.com
|
|
X-Beenthere: fork@spamassassin.taint.org
|
|
X-Mailman-Version: 2.0.11
|
|
Precedence: bulk
|
|
List-Help: <mailto:fork-request@xent.com?subject=help>
|
|
List-Post: <mailto:fork@spamassassin.taint.org>
|
|
List-Subscribe: <http://xent.com/mailman/listinfo/fork>, <mailto:fork-request@xent.com?subject=subscribe>
|
|
List-Id: Friends of Rohit Khare <fork.xent.com>
|
|
List-Unsubscribe: <http://xent.com/mailman/listinfo/fork>,
|
|
<mailto:fork-request@xent.com?subject=unsubscribe>
|
|
List-Archive: <http://xent.com/pipermail/fork/>
|
|
Date: Fri, 06 Sep 2002 13:25:32 -0700
|
|
|
|
|
|
|
|
> Wrong, [VMS-like async io] makes a huge difference in even what I
|
|
> consider small programs.
|
|
|
|
So it sounds as if, to your thinking,
|
|
most useful apps are also trivial.
|
|
Unless each key on my keyboard were
|
|
(to the apps) distinct event sources,
|
|
I can't think of any of my usual job
|
|
mix that would need hundreds, or even
|
|
tens, of async requests; perhaps you
|
|
can explain how nontrivial apps will
|
|
be compellingly useful?
|
|
|
|
> but it's still not built in, who knows when it will be. The point is it's
|
|
> not portable in either case.
|
|
|
|
Does that lack of portability imply it
|
|
isn't generally useful? (When it was
|
|
apparent that TCP networks were useful,
|
|
berkeley sockets could be found even
|
|
on VMS and Win 3.1 boxen)
|
|
|
|
Why would early Unix have run with the
|
|
idea that, if one wishes to do multiple
|
|
things at the same time, one can use a
|
|
group of processes to do them?
|
|
|
|
- they had Multics as a counterexample?
|
|
|
|
- in the days of tiny memories and tapes,
|
|
people were more accustomed to writing
|
|
programs that didn't run entirely in a
|
|
single address space?
|
|
|
|
- one is a great number for an interface,
|
|
as log(1) is 0, and specification can
|
|
be implicit?
|
|
|
|
- some combination of the above?
|
|
|
|
Now, as Hoare says:
|
|
> There are two ways of constructing a software design. One way is to make
|
|
> it so simple that there are obviously no deficiencies and the other is to
|
|
> make it so complicated that there are no obvious deficiencies.
|
|
|
|
As programmers, we've been able to make
|
|
our lives complicated for at least half
|
|
a century; the hardware interrupt gives
|
|
us the rope.
|
|
|
|
Part of Dijkstra's inspiration for THE
|
|
was the counterexample of IBM's multi-
|
|
programmed boxes (were these the same
|
|
ones that inspired Mythical Man Month?)
|
|
and I suppose he would say the question
|
|
is how not to make a mess of it -- how
|
|
should we structure computations so if
|
|
we try to do ten times as many things
|
|
at the same time, reasoning about the
|
|
resulting system is at most ten times
|
|
more complex -- not one hundred, and
|
|
certainly not three and a half million
|
|
times more.
|
|
|
|
Compared to that project, the prospect
|
|
of writing a driver library for various
|
|
vendors' aio implementations seems to
|
|
be truly trivial.
|
|
|
|
-Dave
|
|
|
|
(Oracle, in their quest for portability,
|
|
used to use raw disks for the database.
|
|
This finessed the filesystem issue; did
|
|
it also allow them to roll their own set
|
|
of async drivers?)
|
|
|
|
|