From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <alain@frisch.fr>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by sympa.inria.fr (Postfix) with ESMTPS id 047EC7EE7A
	for <caml-list@sympa.inria.fr>; Thu, 28 Mar 2013 11:54:10 +0100 (CET)
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  alain@frisch.fr) identity=pra; client-ip=193.252.23.212;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr";
  x-conformance=sidf_compatible
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  alain@frisch.fr) identity=mailfrom; client-ip=193.252.23.212;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr";
  x-conformance=sidf_compatible
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@msa.smtpout.orange.fr) identity=helo;
  client-ip=193.252.23.212;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="alain@frisch.fr";
  x-sender="postmaster@msa.smtpout.orange.fr";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuMAADcgVFHB/BfUe2dsb2JhbABDgzu8BoJegRkOAQEJDQoIFAMlgh8BAQU4QAEQCxIGCRYPCQMCAQIBNw4GDQEHAQGIFL5sjxgHg0ADlmeFf44U
X-IPAS-Result: AuMAADcgVFHB/BfUe2dsb2JhbABDgzu8BoJegRkOAQEJDQoIFAMlgh8BAQU4QAEQCxIGCRYPCQMCAQIBNw4GDQEHAQGIFL5sjxgHg0ADlmeFf44U
X-IronPort-AV: E=Sophos;i="4.84,925,1355094000"; 
   d="scan'208";a="9036260"
Received: from msa03.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.212])
  by mail3-smtp-sop.national.inria.fr with ESMTP; 28 Mar 2013 11:54:09 +0100
Received: from [192.168.1.120] ([92.151.115.78])
	by mwinf5d52 with ME
	id Gyu81l00G1hZWdG03yu8zc; Thu, 28 Mar 2013 11:54:09 +0100
Message-ID: <51542152.7010609@frisch.fr>
Date: Thu, 28 Mar 2013 11:54:10 +0100
From: Alain Frisch <alain@frisch.fr>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:20.0) Gecko/20100101 Thunderbird/20.0
MIME-Version: 1.0
To: Philippe Veber <philippe.veber@gmail.com>
CC: Martin Jambon <martin.jambon@ens-lyon.org>, 
 caml users <caml-list@inria.fr>
References: <CAOOOohSzgcZxLOu9qUX1Box1eKyK-DEX7zrEM2GXzjs372jLpQ@mail.gmail.com> <51520CAE.6020009@ens-lyon.org> <CAOOOohTMNd6pW=3Gp8wBc8nggLUCEd9OAEFFV91jz8wEUJMMXg@mail.gmail.com> <51540395.50202@frisch.fr> <CAOOOohR7UT1SjFHMS5w8vpfxg8JD__XA+K2FQC0yzBf6J3kgaQ@mail.gmail.com>
In-Reply-To: <CAOOOohR7UT1SjFHMS5w8vpfxg8JD__XA+K2FQC0yzBf6J3kgaQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Caml-list] Master-slave architecture behind an ocsigen server.

On 03/28/2013 10:39 AM, Philippe Veber wrote:
> Thanks Alain for this detailed description. I did not get why you do not
> use marshalling for computation functions: this should be safe given the
> same code is run in the GUI process and in the calculation
> sub-processes, right?

I believe marshaling of functions did not always work nicely with 
dynlinked code.  More fundamentally, we cannot rely on the generic 
marshaling of data, for the reason I mentioned (some data types require 
special handling), and it's very difficult to know exactly what is 
captured by a closure.  In practice, the computation functions capture 
some values such as global values (global memoization hashtables, etc), 
and it would be wrong to marshal them.


Alain