From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q3ACev1G002110 for ; Tue, 10 Apr 2012 14:40:57 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkADAM8phE8machwl2dsb2JhbABDp2eROioBAQEBAQgWBzuCCQEBAQMBEgIsAQEsCwEPCwsNDSEiEgEFAQoSBhMSEIdeAwYFAwicBgqKXYQtAYYbA4lXBpBhlXCBEY1FPYQm X-IronPort-AV: E=Sophos;i="4.75,399,1330902000"; d="scan'208";a="153391181" Received: from mx1.janestreet.com (HELO nyc-dmz-mxout1.janestreet.com) ([38.105.200.112]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2012 14:40:51 +0200 Received: from nyc-qsv-mail1.delacy.com ([172.25.22.57]) by nyc-dmz-mxout1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1SHaNN-0000x3-Tz for caml-list@inria.fr; Tue, 10 Apr 2012 08:40:49 -0400 Received: from nyc-dmz-mxgoog1.delacy.com ([172.25.224.109] helo=mxgoog1.janestreet.com) by nyc-qsv-mail1.delacy.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1SHaNN-00083s-S3 for caml-list@inria.fr; Tue, 10 Apr 2012 08:40:49 -0400 Received: from mail-vb0-f42.google.com ([209.85.212.42]) by mxgoog1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1SHaNN-0006rS-P1 for caml-list@inria.fr; Tue, 10 Apr 2012 08:40:49 -0400 Received: by vbjk13 with SMTP id k13so3430746vbj.29 for ; Tue, 10 Apr 2012 05:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3m8LHpSzv+xbV5KIm8dGMhVcRR2vO9axrsnwvzmq7vo=; b=HXYwLpyo7yZVOROyjPQAzgUKV1mFiCsnwkDZbeY8llQGqvjt3QdhIhf2QK4b/xxCiG oLdnGWxRdmxSYBP5jRB9OxeulQtzGcpA4kj8luJTfP701FgvYvftDDVk/nkKNUrNi/2F B8YzzNl7X2ht++PgGsANTzJVjIoBEJhNaNzXc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=3m8LHpSzv+xbV5KIm8dGMhVcRR2vO9axrsnwvzmq7vo=; b=g2ReUTgQAvxDN4Sm872TaQvF1jodV4BQ7dn8QDbHVOIXYVZ/ezVVdvEAXONwz731Lj bcKu5ctpbfktXRp2QD6GZe+ycP7mgFNHUTo+nuF6+gpTcQyYbhCc//JWU2DQYFhrkRhK uz9lzkNuG7xCjR8cWmWx2YIXVVadm4nJlTgSnCZLM2RSZNIx8WLhUd6or+KAWJBX2vpb F9tM3CsGdpdxb39u6wZ6TcZWug5rtIP3TsAphWgJb7qFgRAXZVNQ0LYGeU1yggtwP2jL sdrDRQATyKCWFeMmg7IQ1gkHR4zy2tVH68KbAqJnBK5ekAaMCM3fKkAo4oluOt04hp5B gDeQ== MIME-Version: 1.0 Received: by 10.220.202.4 with SMTP id fc4mr5407591vcb.56.1334061649538; Tue, 10 Apr 2012 05:40:49 -0700 (PDT) Received: by 10.52.33.227 with HTTP; Tue, 10 Apr 2012 05:40:49 -0700 (PDT) X-Originating-IP: [38.105.200.252] In-Reply-To: <8CE84D3ACD2A43659ABB1EF6BAFE8A9A@erratique.ch> References: <83F8677AD5E142A3BB0EC27C78C0658B@erratique.ch> <1341A6A9-0273-434A-BCA9-819DACA53FFF@recoil.org> <8CE84D3ACD2A43659ABB1EF6BAFE8A9A@erratique.ch> Date: Tue, 10 Apr 2012 08:40:49 -0400 Message-ID: From: Yaron Minsky To: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Cc: Anil Madhavapeddy , caml-list Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmQY3s2PqOxo4d33LzX6KEjmHuEKkh0AvB/RhMbOyhfc0O1gZRpVCpeTPBPZy7kyG5OLJ/G Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q3ACev1G002110 Subject: Re: [Caml-list] Non-blocking IO interface design On Tue, Apr 10, 2012 at 4:21 AM, Daniel Bünzli wrote: > Anil, > > Thanks for the analysis. > >> The I/O loop is being called twice for the non-blocking version, as it receives >> the `Await signal, does the Unix syscall, and then jumps into decode_src. Presumably >> a full non-blocking version would have to register with a select handler if it >> gets an EAGAIN at this point, > > > Yes. > >> In terms of the number of system calls, the non-blocking one is more efficient, >> as it uses a 16KB buffer versus the 4K reads done by the blocking version. > > > Yes, the 4K reads are a limitation of pervasives channels. For each mechanism I used the largest buffer that the OCaml runtime uses. > >> Looking at the two decoders in src/se.ml, it looks like the non-blocking one >> allocates closures on every loop, which the blocking one doesn't. This is so it >> can store the continuation in d.k for the next loop. > > > Yes, that's a side effect of writing in continuation passing style in general since continuations are often partially applied functions. I believe this particular performance issue is fixed in the upcoming 4.0 release, based on some work by OCamlPro. >> So to summarise, instead of storing a continuation closure, it would probably be better >> to explicitly store the state in d.k to minimise allocation? > > > Maybe, but keep in mind that s-expressions are very simple to parse. It may be obvious in this case but depending on what you decode defining/storing the state may become complex. Cps is an easy and general way to solve the problem while keeping the whole thing reasonably readable. But do you maybe see another pattern that I don't ? > >> The library looks very useful by the way: I have exactly the same issue with several >> Lwt-only protocol libraries we're developing at the moment. Would love to use yours before >> the first release of them to make them more independent of the underlying I/O mechanism... > > > That would be nice, I'm glad if you can somehow reuse the pattern. > > > Best, > > Daniel > > -- > Caml-list mailing list.  Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >