Language Bindings for Erlang Again
Wed Jun 7 02:38:19 CEST 2006
> 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
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. ;-)
More information about the erlang-questions