From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 1FE6DBBAF for ; Mon, 25 Oct 2010 00:51:50 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPdUxEzVuiYS/2dsb2JhbAChXnG6JA2FOwQ X-IronPort-AV: E=Sophos;i="4.58,233,1286143200"; d="scan'208";a="75670042" Received: from solaria.dimino.org ([213.186.38.18]) by mail4-smtp-sop.national.inria.fr with ESMTP; 25 Oct 2010 00:51:49 +0200 Received: from aurora (localhost.localdomain [127.0.0.1]) by solaria.dimino.org (Postfix) with ESMTP id 9291B80048; Mon, 25 Oct 2010 00:51:48 +0200 (CEST) Received: by aurora (Postfix, from userid 1000) id 12ED1416AA; Mon, 25 Oct 2010 00:50:37 +0200 (CEST) Date: Mon, 25 Oct 2010 00:50:37 +0200 From: =?iso-8859-1?Q?J=E9r=E9mie?= Dimino To: Anil Madhavapeddy Cc: Jake Donham , Jon Harrop , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Asynchronous IO programming in OCaml Message-ID: <20101024225037.GA8999@aurora> References: <044101cb7367$10f94b30$32ebe190$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam: no; 0.00; ocaml:01 anil:01 event-driven:01 off-list:01 async:01 wrote:01 caml-list:01 kegel:01 interfaces:01 interfaces:01 structures:02 kernel:02 asynchronous:03 programming:03 asynchronous:03 On Sun, Oct 24, 2010 at 01:54:50PM -0700, Anil Madhavapeddy wrote: > This should work fine for a couple of thousand clients or so, but you'll > begin to see degradation as the number of clients increase. This is > because LWT internally uses select(2) to wait for file-descriptors, and > not the newer kqueue(2) or epoll(2) interfaces. You can read more about > the "C10K problem" here: [3]http://www.kegel.com/c10k.html > I've got a stripped-down version of LWT that uses these newer event-driven > kernel interfaces (and so should be able to cross the 10,000 client > barrier fairly easily), but it won't be ready for release for another > month or so.  Drop me an email off-list if you want to try it out earlier. I made an implementation of lwt using libev [1]. I tested it with ocsigen and ab but the result was always a bit better with select than with epoll. That is why i did not replace select by libev in the main branch. In fact i never found the source of any benchmark comparing select to epoll on the web. > Async disk I/O under Linux is annoyingly problematic if you aren't using > direct I/O (and hence page/block-aligned structures). Avoid if possible :) The next version of Lwt will support asynchronous disk I/O by using mincore + mmap. It is already in the development version. Jérémie [1] http://www.dimino.org/cgi-bin/darcsweb.cgi?r=lwt-libev;a=summary