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=1.4 required=5.0 tests=SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 71993BC6B for ; Fri, 22 Jun 2007 12:54:29 +0200 (CEST) Received: from mta4.srv.hcvlny.cv.net (mta4.srv.hcvlny.cv.net [167.206.4.199]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5MAsSsC016925 for ; Fri, 22 Jun 2007 12:54:29 +0200 Received: from [192.168.15.101] (ool-457da870.dyn.optonline.net [69.125.168.112]) by mta4.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JK100LMEAASVCI0@mta4.srv.hcvlny.cv.net> for caml-list@yquem.inria.fr; Fri, 22 Jun 2007 06:54:28 -0400 (EDT) Date: Fri, 22 Jun 2007 06:57:07 -0500 From: Serge Aleynikov Subject: Re: [Caml-list] ocaml dll in an Erlang runtime In-reply-to: <467B8230.9090904@inria.fr> To: Xavier Leroy Cc: "Ulf Wiger (TN/EAB)" , caml-list@yquem.inria.fr Message-id: <467BB913.6000903@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <6616D98C65DD514BA2E1DDC5F92231550228B6EB@esealmw115.eemea.ericsson.se> <467B8230.9090904@inria.fr> User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) X-j-chkmail-Score: MSGID : 467BAA64.001 on concorde : j-chkmail score : X : 0/20 1 0.000 -> 1 X-Miltered: at concorde with ID 467BAA64.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 erlang:01 runtime:01 erlang:01 run-time:01 threads:01 byte-code:01 model:01 initialized:01 threads:01 prototyping:01 coupling:01 ocaml:01 doable:01 interop:01 While using serialized streams of data between processes is the easiest interoperability approach it is also the slowest of the two supported by Erlang run-time. In the second approach that uses the same address space Erlang maintains a pool of OS threads separate from the ones executing Erlang byte-code that can be used to make asynchronous blocking calls of C functions. If this model is used as far as I understand separate Caml run-times would have to be initialized per pooled thread managed by Erlang. Otherwise garbage collection on the Caml side (that uses a single mutex) would block all pooled OS threads currently executing Caml closures while being garbage collected that would penalize performance. Is this a feasible approach? Would it lead to too much of memory overhead? (Erlang doesn't have the same issue because user-level light-weight processes don't share heaps and garbage collection happens on a light-weight process level without stalling other processes). Serge Xavier Leroy wrote: >> Would any of you be interested in prototyping a semi-tight coupling >> between Erlang and OCaml? [...] Do you think it's doable? > > I haven't looked closely at the Erlang interop facilities, but I think > it is doable. Here are some remarks based on previous > interoperability experiences with Caml. > > The first step is to find a good mapping between data structures of > the two languages. When both are statically typed, this can be > difficult as both type systems try to impose their views. > When at least one of the languages is dynamically typed, it's easier. > > One approach is to define a Caml datatype that reflects the > "universal" type of the dynamically-typed language, e.g. S-exprs in > the case of Lisp, and provide low-level interface functions to > exchange values of this type. > > Conversions between this Caml representation of the universal type and > regular Caml data structures can be written manually in Caml, or maybe > automatically generated in the style of Markus Mottl's Sexplib tool > or Jeremy Yallop's Deriving mechanism. > > Function values can be difficult to exchange in both directions. It > might be possible to encapsulate Erlang functions as an abstract Caml > type, with an appropriate "apply" primitive. I don't know if this can > be made to work in the other direction, e.g. encapsulate Caml > functions as some opaque thing on the Erlang side. At any rate, for > many applications, exchange of first-order data structures can be > enough. > > If the Caml code and the Erlang code live in the same address space, > the actual exchange of data can be done through the C interfaces of > both languages. This is what we did for the Caml/Java interface, > going through the Java Native Interface and OCaml's C interface. > The two GC can be made to cooperate. However, data cycles that spawn > the two heaps will never be garbage-collected. > > As others mentioned, it is possible to encapsulate Caml code and the > Caml runtime system as a DLL, at least for x86 under Linux and Windows. > For the Caml/Java interface, we used the reverse embedding: the Caml > code would link with the Java runtime system (as a library), which > would then load the Java code. > > Apparently, Erlang makes it possible to communicate between separate > processes using byte streams. This is an original feature that could > significantly simplify the interface: the Caml side could be written > entirely in Caml, bypassing low-level C interface code. > > I guess that's all I can say at this point, but feel free to ask > questions. > > - Xavier Leroy > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >