[erlang-questions] FFI for Erlang: patches and draft EEP

[Alceste Scalas]

Il giorno mar, 11/09/2007 alle 15.05 +0200, Claes Wikstrom ha scritto:
> call erlang--> C and binary() data: Is the binary data copied
> or does the C function get a pointer/size pair - the latter
> would be optimal.

The C side just gets a pointer to the beginning of the binary data, that
is never copied.  If the binary size is also required, you could pass
size(Binary) as a function call argument.


> return C --> erlang - I can't seem to find any ways for the
> C code to return a binary() back to erlang ?? This is IMHO
> necessary

The current FFI implementation, taken alone, does *not* allow the C side
to fiddle with the Erlang VM (e.g. by allocating binaries or other
terms).

This issue could be overcomed in three ways:

     1. using a complete API for handling Erlang terms on the C side
        (not existing yet for linked-in drivers);
     2. developing a small linked-in driver, that uses
        erlang:port_control/3 for stuff like returning binaries
        (allocated with driver_alloc_binary()).  Other functions that
        don't play with Erlang terms may be called directly with
        ffi:call/2 and ffi:call/3, without having to increase the driver
        glue code;
     3. another way I didn't think about :-)

The ideal solution would be (1), and it could even be an extension of
the Erlang FFI draft EEP [1].  My idea, however, was to do one thing a
time.

Regards,

alceste

Notes:

  [1] Indeed, it would be trivial to extend the FFI interface to
      pass Erlang terms to the C side, thus allowing to develop 
      functions with the power of BIFs.  These functions, however,
      would need to be compiled against the Erlang VM header files;
      and since they are not "public", they would need to be
      recompiled in order to match the Erlang/OTP version in use.
      This is a complex issue, that is probably worth a dedicated
      EEP.
-- 
Alceste Scalas <alceste@REDACTED>
CRS4 - http://www.crs4.it/