From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr 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 44C40BBAF for ; Mon, 25 Oct 2010 13:10:25 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGcCxUzVuiYS/2dsb2JhbAChXXG6NA2FOwQ X-IronPort-AV: E=Sophos;i="4.58,235,1286143200"; d="scan'208";a="75756177" Received: from solaria.dimino.org ([213.186.38.18]) by mail4-smtp-sop.national.inria.fr with ESMTP; 25 Oct 2010 13:10:25 +0200 Received: from aurora (localhost.localdomain [127.0.0.1]) by solaria.dimino.org (Postfix) with ESMTP id 2529580048; Mon, 25 Oct 2010 13:10:24 +0200 (CEST) Received: by aurora (Postfix, from userid 1000) id E1A97416AA; Mon, 25 Oct 2010 13:10:22 +0200 (CEST) Date: Mon, 25 Oct 2010 13:10:22 +0200 From: =?iso-8859-1?Q?J=E9r=E9mie?= Dimino To: Goswin von Brederlow Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Asynchronous IO programming in OCaml Message-ID: <20101025111022.GA32282@aurora> References: <044101cb7367$10f94b30$32ebe190$@com> <20101024225037.GA8999@aurora> <87y69mk6jm.fsf@frosties.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87y69mk6jm.fsf@frosties.localdomain> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam: no; 0.00; ocaml:01 0200,:01 byte:01 buffer:01 trivial:01 afaik:01 synchronous:01 wrote:01 caml-list:01 data:02 cached:02 cached:02 seems:03 asynchronous:03 programming:03 On Mon, Oct 25, 2010 at 10:42:05AM +0200, Goswin von Brederlow wrote: > Doesn't that mean you have to do polling of all pending I/O? That seems > horrible ineficient (you check them all every time) or slow I/Os can > starve quick ones (you only check the oldest ones). No. In the current implementation, when we want to read a file, we mmap it, then test it with mincore. If it is not cached in memory, we first wait a bit, test again and if it is still not available, we launch a thread which try to read the first byte of the mmapped buffer. If the file is not cached, then the time needed to launch a thread is negligible compared to the time needed to fetch data from the disk. > The nice thing about libaio is that you get events as I/O completes and > you get many events in one simple syscall. Doing thousands of I/O > requests in parallel is trivial there. AFAIK libaio is linux-specific and not impelemted for all filesystems. Moreover it transparently fallback to synchronous IOs when asynchronous IOs are not available, so there is no reliable way to test whether IOs will block or not. Jérémie