From fork-admin@xent.com Fri Sep 6 11:41:33 2002 Return-Path: Delivered-To: yyyy@localhost.example.com Received: from localhost (jalapeno [127.0.0.1]) by jmason.org (Postfix) with ESMTP id E8CAD16F6F for ; 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 ; 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@example.com Received: from panacea.canonical.org (ns1.canonical.org [209.115.72.29]) by xent.com (Postfix) with ESMTP id 7586129427E for ; 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@example.com 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@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, 6 Sep 2002 04:26:44 -0400 (EDT) X-Spam-Status: No, hits=-6.2 required=7.0 tests=AWL,KNOWN_MAILING_LIST,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 version=2.50-cvs X-Spam-Level: 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 hasn't been without this feature, and in fact has had it since you were in elementary school, and operating systems without it don't "totally suck for nontrivial apps". For what it's worth, glibc has actually implemented the aio_* calls for a while, just in a way that doesn't scale to large numbers of concurrent I/O requests. I find references to the glibc implementation as far back as 1999 and glibc 2.1.1, and I could probably find much earlier references if I had time: http://sources.redhat.com/ml/libc-hacker/1999-12/msg00070.html (more details at http://www.atnf.csiro.au/people/rgooch/linux/docs/io-events.html; details on the SGI patch are at http://oss.sgi.com/projects/kaio/faq.html) > > Unix has been multiprocess since 1969, and most Unix implementations > > have supported multithreading for a decade or more. > > And most UNIX is still kinda-sorta supporting the pthreads (POSIX) > interface, each in their own 7/8 implementation. You're safe if you > stick to the basics. Your original complaint was that Unix didn't do multithreading or multiprogramming well. Now that I've pointed out how obviously idiotic that claim is, you've amended your complaint: now, although individual Unixes do these things well, you complain that their implementations are not entirely conformant with the POSIX threads specification. Well, that's probably true, but I haven't written pthreads programs in C much myself, so I can't confirm it from my own experience. But, even if it's true, it's not a very good reason to prefer Windows. I'm sure you can provide examples of bugs in particular threading implementations. Spare us. Just shut up. -- Kragen Sitaker Edsger Wybe Dijkstra died in August of 2002. The world has lost a great man. See http://advogato.org/person/raph/diary.html?start=252 and http://www.kode-fu.com/geek/2002_08_04_archive.shtml for details.