From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q3A8MpTZ026633 for ; Tue, 10 Apr 2012 10:22:51 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocDAJHsg09KN1ZKm2dsb2JhbABDhXOzZAEBAQEBCAkLCRQnggkBAQQBI1YFCwsaAhgOAgI9ChAGG4gBBQSreotNgS+OGjVjBJtLjUA X-IronPort-AV: E=Sophos;i="4.75,398,1330902000"; d="scan'208";a="139625761" Received: from mail6.webfaction.com (HELO smtp.webfaction.com) ([74.55.86.74]) by mail4-smtp-sop.national.inria.fr with ESMTP; 10 Apr 2012 10:22:44 +0200 Received: from heyho.local (25-232.197-178.cust.bluewin.ch [178.197.232.25]) by smtp.webfaction.com (Postfix) with ESMTP id AA4B120C427C; Tue, 10 Apr 2012 03:21:11 -0500 (CDT) Date: Tue, 10 Apr 2012 10:21:06 +0200 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Anil Madhavapeddy Cc: caml-list Message-ID: <8CE84D3ACD2A43659ABB1EF6BAFE8A9A@erratique.ch> In-Reply-To: <1341A6A9-0273-434A-BCA9-819DACA53FFF@recoil.org> References: <83F8677AD5E142A3BB0EC27C78C0658B@erratique.ch> <1341A6A9-0273-434A-BCA9-819DACA53FFF@recoil.org> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [Caml-list] Non-blocking IO interface design 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. > 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