view release on metacpan or  search on metacpan

share/SpamAssassin/easy_ham/00448.18e06f65c923e685fb4f72d90962c217  view on Meta::CPAN

From fork-admin@xent.com  Fri Sep  6 11:41:33 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 E8CAD16F6F
	for <jm@localhost>; Fri,  6 Sep 2002 11:39:33 +0100 (IST)
Received: from jalapeno [127.0.0.1]
	by localhost with IMAP (fetchmail-5.9.0)
	for jm@localhost (single-drop); Fri, 06 Sep 2002 11:39:33 +0100 (IST)
Received: from xent.com ([64.161.22.236]) by dogma.slashnull.org
    (8.11.6/8.11.6) with ESMTP id g868XVW25919 for <jm@jmason.org>;
    Fri, 6 Sep 2002 09:33:31 +0100
Received: from lair.xent.com (localhost [127.0.0.1]) by xent.com (Postfix)
    with ESMTP id 429D3294289; Fri,  6 Sep 2002 01:27:05 -0700 (PDT)
Delivered-To: fork@spamassassin.taint.org
Received: from panacea.canonical.org (ns1.canonical.org [209.115.72.29])
    by xent.com (Postfix) with ESMTP id 7586129427E for <fork@xent.com>;
    Fri,  6 Sep 2002 01:26:11 -0700 (PDT)
Received: by panacea.canonical.org (Postfix, from userid 1004) id
    9369B3F4EB; Fri,  6 Sep 2002 04:26:44 -0400 (EDT)
From: kragen@pobox.com (Kragen Sitaker)
To: fork@spamassassin.taint.org
Subject: Re: asynchronous I/O (was Re: Gasp!)
Message-Id: <20020906082644.9369B3F4EB@panacea.canonical.org>
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,  6 Sep 2002 04:26:44 -0400 (EDT)

Adam Beberg writes:
> On Tue, 3 Sep 2002, Kragen Sitaker wrote:
> > Unix acquired nonblocking I/O in the form of select() about 23 years
> > ago, and Solaris has had the particular aio_* calls we are discussing
> > for many years.
> 
> select() "scaling" is a joke at best, and I know you know that. poll() is
> only a bit better.

Not only do I know that, the post to which you were responding
explained that, with somewhat more detail than "a joke".  As you
should know, but evidently don't, poll() isn't even "a bit better" ---
in fact, it's about an order of magnitude worse --- for dense file
descriptor sets, which is the normal case.  (Except on operating
systems where select() isn't a system call but a library routine that
calls poll().)

> > Very few applications need the aio_* calls --- essentially only
> > high-performance RDBMS servers even benefit from them at all, and
> > most of those have been faking it fine for a while with multiple
> > threads or processes.  This just provides a modicum of extra
> > performance.
> 
> Wrong, it makes a huge difference in even what I consider small programs.

Why don't you explain this in more detail?

> > Although I don't have a copy of the spec handy, I think the aio_* APIs
> > come from the POSIX spec IEEE Std 1003.1-1990, section 6.7.9, which is
> > 13 years old, and which I think documented then-current practice.
> > They might be even older than that.
> 
> Yes, SGI has a patch to the linux kernel to implement the aio_ interfaces,
> but it's still not built in, who knows when it will be. The point is it's
> not portable in either case.

You originally said:

  Could it be? After 20 years without this feature UNIX finally
  catches up to Windows and has I/O that doesnt [sic] totally suck for
  nontrivial apps? No way!

The point --- my point, the point I was discussing; please don't try
to tell me you were trying to make a different point, because I don't
care --- is that you had no clue what you were talking about; Unix