Version française
Home     About     Download     Resources     Contact us    
Browse thread
ocaml dll in an Erlang runtime
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Serge Aleynikov <saleyn@g...>
Subject: Re: [Caml-list] ocaml dll in an Erlang runtime
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
>