From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 1BCC1BBAF for ; Mon, 26 Jul 2010 10:19:24 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkCAEriTEzRVaE0mGdsb2JhbACDFJxECBUBAQEBAQgJDAcRIq4XO4IQhQAuiFQBAQMFgSGDHXMEhAOHKA X-IronPort-AV: E=Sophos;i="4.55,260,1278280800"; d="scan'208";a="64404741" Received: from mail-fx0-f52.google.com ([209.85.161.52]) by mail1-smtp-roc.national.inria.fr with ESMTP; 26 Jul 2010 10:19:23 +0200 Received: by fxm8 with SMTP id 8so6780401fxm.39 for ; Mon, 26 Jul 2010 01:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=0drBEYFhSPBKwXv906Tow+KE3/kNkwnH1u8nFaUtoMs=; b=Oh7O0tvkzEzMCP0uB0LZmBKwlMIcoxFytL82jp5IDgs0qoQPontAzEEzW/Zrfvp2gG GvBuggjQVNNu6kTdnQgC317nf4iMF276I8DDuOtWDazYwBaziQ0nPgS15KYnqr0sY3Bg CHBuB/fEUwu9onq2vrwylQqcvVh5dWMPpvk3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=kyZ/r2ME7jis/2CbyNQ3lXjy9gX8frnfJ2ih0eJ9cQ+33kgBN+15oTot7CLkxSVELc QVryWDxj0EH3NSL4ardmE3FuAg4FNRghicf04eP+qxeUuTyWIOMV4hKk2LQvkarwg6CX 8FvyVBFvAktiI3BvcfV4ckNkN35WdKL8bWoPs= Received: by 10.223.103.148 with SMTP id k20mr5851163fao.101.1280132363443; Mon, 26 Jul 2010 01:19:23 -0700 (PDT) Received: from deb0 ([79.114.80.43]) by mx.google.com with ESMTPS id e20sm1278846fak.47.2010.07.26.01.19.22 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Jul 2010 01:19:23 -0700 (PDT) Date: Mon, 26 Jul 2010 11:19:20 +0300 From: =?UTF-8?B?VMO2csO2aw==?= Edwin To: =?UTF-8?B?SsOpcsOpbWll?= Dimino Cc: Dario Teixeira , caml-list@yquem.inria.fr Subject: Re: [Caml-list] scalable web apps Message-ID: <20100726111920.22882a95@deb0> In-Reply-To: <20100726075901.GA5561@aurora> References: <914B9960-EBC8-439B-B7F8-A852859B522F@gmail.com> <407966.39005.qm@web111512.mail.gq1.yahoo.com> <20100726102904.10ed4768@deb0> <20100726075901.GA5561@aurora> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; scalable:01 ocaml:01 linux's:01 manpage:01 val:01 edwin:98 26,:98 edwin:98 threads:01 threads:01 wrote:01 wrote:01 unix:01 unix:01 readable:01 On Mon, 26 Jul 2010 09:59:01 +0200 J=C3=A9r=C3=A9mie Dimino wrote: > On Mon, Jul 26, 2010 at 10:29:04AM +0300, T=C3=B6r=C3=B6k Edwin wrote: > > Lwt's Lwt_preemptive seems to allow one to use 'preemptive > > threads' (which I assume are just usual OCaml threads). > > So would it be possible to put the file I/O on Lwt_preemptive.detach > > threads? >=20 > Yes. >=20 > > Has anyone tried to measure the performance of doing that? >=20 > Yes, i tried it some time ago with two small C programs which were > just reading a file on the disk. One doing read operations in a > simple loop, and one launching a thread for each read operation (or > reusing the same thread). The threaded version was about 100 times > slower than the non-threaded one. >=20 > BTW it is planed to add some kind of asynchronous file I/O support in > Lwt by using mmap and mincore. How about using linux's AIO and eventfd? Manpage of eventfd says: "When used in the kernel, an eventfd file descriptor can provide a kernel-userspace bridge allowing, for example, functionalities like KAIO (kernel AIO) to signal to a file descriptor that some operation is complete. A key point about an eventfd file descriptor is that it can be monitored just like any other file descriptor using select(2), poll(2), or epoll(7). This means that an application can simultaneously monitor the readiness of "tra=E2=80=90 ditional" files and the readiness of other kernel mechanisms that support the eventfd interface." And looks like libaio-ocaml has support for eventfd in AIO: val fd : context -> Unix.file_descr (** return eventfd associated with the context *) I think there could be a Lwt_unix.read_aio that is just like Lwt_unix.read, except it checks the eventfd descriptor for being readable instead of the original fd, and use Aio.read instead of usual read, etc. Best regards, --Edwin