1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
|
From fork-admin@xent.com Sat Sep 7 21:52:42 2002
Return-Path: <fork-admin@xent.com>
Delivered-To: yyyy@localhost.example.com
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@example.com
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@example.com
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@example.com
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:fork-request@xent.com?subject=help>
List-Post: <mailto:fork@example.com>
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
X-Spam-Status: No, hits=-7.6 required=7.0
tests=IN_REP_TO,KNOWN_MAILING_LIST,QUOTED_EMAIL_TEXT,
SPAM_PHRASE_00_01
version=2.50-cvs
X-Spam-Level:
> 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?)
|
