[erlang-questions] Wrapping C libraries in pure Erlang

[Serge Aleynikov]

Part of the issue is that this approach would make it possible for a 
function call inside a 3rd party library to block for a while.  Since 
Erlang's concurrency is dependent on the fact that function calls are 
very short, and the emulator uses reduction-based counting for giving 
CPU slices to each light-weight process a blocking call would 
significantly inhibit concurrency.

Drivers solve this problem by allowing asynchronous invocation of 
blocking functions in the context of threads different from the 
emulator(s) (*).  In case of a driver or a port, once you are on the 
C-side of coding interface, you can make calls to any 3rd party library 
directly without needing FFI (except for cases of functions with 
variable arguments), which may bring you to the question of why bother 
with such an Erlang library if you already have ports and drivers that 
can be written in C or even ei interface for writing C-nodes that can 
make any C-calls safely with respect to the emulator?

There were attempts at somewhat automating generation of a driver using 
EDTK tooklit (**) or Dryverl (***) that some people found useful. 
Others prefer having more control and coding drivers by hand.

Regards,

Serge

(*)   Emulators can run in multiple threads if SMP support is enabled.
(**)  http://www.snookles.com/erlang/edtk/
(***) http://forge.objectweb.org/forum/forum.php?forum_id=1018


Denis Bilenko wrote:
> Hello,
> 
> Python has a very nice package in its stdlib -- ctypes. It allows
> wrapping C libraries in pure Python. ctypes' implementation is based
> on libffi, C library for handling dynamic libraries.
> 
> I wonder if Erlang could have such library, implemented as a driver on
> top of libffi, or any other way that serves the goal. Excluding
> intermediate IDL and associated compilation phase
> simplifies interop a lot. Surely, one could crash an interpreter more
> easily, but that can be mitigated by separating unsafe code in another
> node.
> 
> A couple examples from ctypes documentation translated into (wishful) Erlang:
> 
> %% Functions return int by default
> 1> cee:call(Libc, time, [null]).
> 1150640792
> 
> %% Parameters' types deduced when there exists a well-defined mapping
> 2> cee:call(Libc, printf, ["%d bottles of beer\n", 42]).
> 
> %% Ambiguity must be resolved by user
> 3> cee:call(Libc, printf, ["%d bottles of beer\n", 42.5]). % float or double?
> ** exited: {{nocatch,{argument_error, 2}},
>             [{erl_eval,do_apply,5},{shell,exprs,6},{shell,eval_loop,3}]} **
> 
> 4> cee:call(Libc, printf, ["int %d, double %f\n", 1234, cee:double(3.14)]).
> int 1234, double 3.1400001049
> 31
> 
> %% where cee:double is something like
> double(N) when is_float(N) -> {c_double, N}.
> 
> %% This example is somewhat different from Python's,
> %% since Erlang disallows mutable data. Although, that
> %% doesn't seem a big problem, as we can make more copies.
> 5> cee:call(Libc, sscanf, ["1 3.14 Hello", "%d %f %s",
>                            output(c_int), output(c_float),
>                            output(char_array(100))]).
> {3, [1, 3.1400001049, "Hello"]}.
> 
> (ctypes has much more than that, including passing python
> functions as callbacks)
> 
> One useful application would be accessing system calls not
> covered by existing BIFs/drivers (native GUI goes in this
> category)
> 
> I would like to hear any comments, especially from people who
> know something about Erlang internals (I don't):
> Would it be hard to implement?
> Has anyone already thought of something like that?
> 
> Denis.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>