From fork-admin@xent.com Sat Sep 7 21:52:42 2002 Return-Path: Delivered-To: yyyy@localhost.example.com Received: from localhost (jalapeno [127.0.0.1]) by jmason.org (Postfix) with ESMTP id 8281416F18 for ; 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 ; 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 ; 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 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: List-Post: List-Subscribe: , List-Id: Friends of Rohit Khare List-Unsubscribe: , List-Archive: 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?)