Language Bindings for Erlang Again

[Romain Lenglet]

> On Tue, Jun 06, 2006 at 08:21:06PM +0200, Ulf Wiger wrote:
> }
> }  You can do this pretty much today, since you can write
> linked-in drivers }  that are dynamically linked in (using
> erl_ddll), registered with a unique }  name, and called
> synchronously using port_call(). There are even support } 
> functions for letting the driver code return any erlang term.
> The main }  drawback compared to BIFs is that the data is
> copied between erlang and C.

First, using port_call/3, terms are not only copied, but also 
encoded/decoded in the external format, which by the way 
requires every driver to statically link to libei.a from 
erl_interface.

And as I wrote also in my email, unlike a BIF, a driver can't 
spawn processes, etc. All a driver can do with the emulator 
using the driver API is basically to exchange raw binary data or 
encoded terms with its port owner (some functions also allow it 
to send messages to arbitrary processes). This is far from the 
possibilities offered by BIFs.


Vance Shipley wrote:
> I was going to point this out myself.  As far as copying goes,
> as I understand it, large binaries are not copied.

No, only when using port_command/2. And using port_command/2, 
only raw binary data is exchanged: if you want to send terms, 
you have for instance to encode them using term_to_binary/1, and 
decode them on the C side using erl_interface. That is what I do 
in Dryverl. And beware of packing of binaries that can occur in 
port_command/2! How I deal in Dryverl with binary packing in 
port_command/2 is a scary story. ;-)

-- 
Romain LENGLET