From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 01606BC6C for ; Mon, 4 Jun 2007 20:01:00 +0200 (CEST) Received: from smtp.janestcapital.com (www.janestcapital.com [66.155.124.107]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l54I0xX5003725 for ; Mon, 4 Jun 2007 20:01:00 +0200 Received: from [172.25.129.161] [38.96.172.125] by janestcapital.com with ESMTP (SMTPD-9.10) id A366031C; Mon, 04 Jun 2007 14:01:10 -0400 Message-ID: <46645359.80500@janestcapital.com> Date: Mon, 04 Jun 2007 14:00:57 -0400 From: Brian Hurt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Bryant Cc: Benedikt Grundmann , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Faking concurrency using Unix forks and pipes (ray tracing results) References: <200706041156.16521.jon@ffconsultancy.com> <67BC38F1-55DA-46F6-B35E-E728F7B1154B@valdosta.edu> <9b415f950706040850v586a285ax1448d23c0c78a375@mail.gmail.com> <1B7A6678-6C9E-4356-802C-5CA5168A27CC@valdosta.edu> <9b415f950706040933r22e1560fhc088368ccb8444fa@mail.gmail.com> <9BE9B524-35AA-43AC-8A63-4153E3AD672F@valdosta.edu> In-Reply-To: <9BE9B524-35AA-43AC-8A63-4153E3AD672F@valdosta.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 4664535B.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; forks:01 grundmann:01 marshaled:01 ocaml:01 mutable:01 synchronous:01 mutable:01 buf:01 buffer:01 2007,:98 unix:01 wrote:01 wrote:01 caml-list:01 functions:01 Jonathan Bryant wrote: > > On Jun 4, 2007, at 12:33 PM, Benedikt Grundmann wrote: > >> >> It looks a bit more complex, but that's just to avoid big strings in >> case of big messages >> (e.g. with the "simple" interface you end up with the "same" content >> in memory twice). > > > I think big strings are unavoidable in this case. They can be broken > up at the protocol level for sending, but a large data structure is > going to be marshaled into a big string. As far as same content in > memory twice, that should be the case for pure values even in a > regular OCaml program. As for mutable values, they shouldn't be sent > over a channel to begin with. Once channels are available though, > creating a synchronous mutable cell is only a few lines of code. > (Check out Reppy's book/papers). I'm wondering if inversion of control isn't an answer here. The idea is to have a function of type buf_t -> string -> unit. Instead of building up a giant string, the of_* functions would call this function on small strings. Not unlike Buffers. But instead of building up in memory, these function would fill a buffer and then send it off. Brian