From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 415C17EE51 for ; Mon, 15 Apr 2013 22:59:12 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.126.187; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.126.187; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@moutng.kundenserver.de designates 212.227.126.187 as permitted sender) identity=helo; client-ip=212.227.126.187; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@moutng.kundenserver.de"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8BAMFobFHU4367k2dsb2JhbABQFoMmgzC9VYEHFg4BAQEBBwsLCRQDJYIfAQEEASMELiQOAgsSCAImAgIbLg4GExuHcwoIqSySPQSBH4dvhgUHY4FLgRMDjimJfYRkjgoP X-IPAS-Result: Av8BAMFobFHU4367k2dsb2JhbABQFoMmgzC9VYEHFg4BAQEBBwsLCRQDJYIfAQEEASMELiQOAgsSCAImAgIbLg4GExuHcwoIqSySPQSBH4dvhgUHY4FLgRMDjimJfYRkjgoP X-IronPort-AV: E=Sophos;i="4.87,479,1363129200"; d="scan'208";a="13393356" Received: from moutng.kundenserver.de ([212.227.126.187]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 15 Apr 2013 22:59:11 +0200 Received: from office1.lan.sumadev.de (dslb-084-059-069-246.pools.arcor-ip.net [84.59.69.246]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LaJMk-1UpajI2GZ4-00mNr1; Mon, 15 Apr 2013 22:59:10 +0200 Received: from [192.168.0.110] (ip-5-146-55-186.unitymediagroup.de [5.146.55.186]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 1856EC00C8; Mon, 15 Apr 2013 22:59:10 +0200 (CEST) Message-ID: <1366059549.3744.14.camel@zotac> From: Gerd Stolpmann To: Christophe Raffalli Cc: Caml List Date: Mon, 15 Apr 2013 22:59:09 +0200 In-Reply-To: <516BC56B.7090903@univ-savoie.fr> References: <516BC56B.7090903@univ-savoie.fr> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Provags-ID: V02:K0:7wobN7O3b5i03zmx8EFgrJPrEVWCoIcdso8FAitFfXa 8UojWNI7BVIhbf6Tjp5QW7tAaAjn5bk4klCg+4ZX8yByWWygdI Qi20F1VlClchuS4QmPn1q2jIh3U+zNX+ZkJn6LLu+lVn6zAhli mQ5X618YXX4NR9ib9cXXq2O6Yh1xFJ2QkXkKhip+gS3xx0uo6Q FbrpRoOolJA0GhJSI/pQKfUXTyzpFtMdeOiFjUFMNdh0hFLVoP SXSQNv6TohlJLw+B8joRk5ePihuT/mSmMzVjodiIT7fyFh6s19 SAiXTcqT2XZK+t8rCVTjJsWcfYWQ5SqZ+fidcP+BfGmQNK5934 Z/mbpyCU0wPFTCzTld49362q43UNvb6+hLn+Iu7NC Subject: Re: [Caml-list] Closures serialization and hash. Am Montag, den 15.04.2013, 11:16 +0200 schrieb Christophe Raffalli: > Hello, > > The usual limitation of serialization and hashing of closures is sometimes painful, especially with > the current temptation of parallelisation. I am involved in two projects/sofwares that are impacted > by this: bindlib[1] (where data structure using bound variables uses closures) and Patoline[2] > (where documents using animation and compiled with the "Bin" driver contain closures). > > There is a simple way out of this problem, at least for libraries where the function pointer > in closure can be predicted enough : > > - use a table associating function "names" (position in the .cmo, or the lambda-tree or anything > portable) to source code adresses. The function name should be portable across architecture and > distinct binary using common librairies. > > - (1) fill this table by calling a function "register_code_pointer : ('a -> 'b) -> unit" > > - (2) or even better offer a linking option to register all closures from some compilation unit. > > With this, serialisation and hashing functions could use those "names" instead of addresses. Thus we > would have reproducible hash and portable serialization for registered functions in closure. > > I will probably try this soon by adding custom version of Hash and Marshal to bindlib using (1) ... > But support from real OCaml giving (2) would be much better. > > So my question is : are you ennoyed by this problem, and, if yes, would you be happy with the above > solutions. For the Plasma map/reduce platform, a similar problem arises. It starts the same executable on several computers, and it is required to run functions on remote instances. I've introduced so-called "registered functions" to address this problem: http://plasma.camlcity.org/plasma/dl/plasma-0.6.2/doc/html/Plasmamr_toolkit.html#2_Registeredfunctions I've added some camlp4 support to make the registration less painful, so you can simply do let f = <:rfun< variables -> body >> This concept also distinguishes between local arguments and remote arguments. The local arguments are normal function arguments, and are not marshalled, as if you did let f localarg = <:rfun ...>> (only that this form would not run any registration code). The remote arguments are the marshalled ones. Of course, there is still the problem that we cannot ensure that the registration of the function is done before its use, simply because we don't know whether the registration is done in a toplevel module (I guess this is why you'd prefer (2) ). Gerd > > Cheers, > Christophe > > [1] http://www.lama.univ-savoie.fr/~raffalli/bindlib > [2] http://www.patoline.com > -- ------------------------------------------------------------ Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------