[erlang-questions] RFC: Erlang FFI

Denis Bilenko denis.bilenko@REDACTED
Thu Aug 9 13:03:38 CEST 2007

On Tue, 07 Aug 2007 Alceste Scalas wrote:
> Hello,
> following the rules of the EEP workflow [1], I'd like to know your
> opinions about extending Erlang with a Foreign Function Interface
> (FFI).
> I've got an implementation based on GCC's FFI library [2], that is
> mostly complete [3] and tested on GNU/Linux on AMD64.  The first
> part of the following description refers to this implementation,
> while the rest of the email contains ideas for possible
> enhancements.

That's great news. I've asked for such a library sometime ago:
and even tried to implement it but using driver api, not BIFs.
I have not finished it (got new job), but did manage to call simple
functions, e.g. printf:
It's nice to see someone has done it.
Erlang will become more interesting to the masses once
such a library will come out.

On Wed, 08 Aug 2007 Scott Lystig Fritchie

> There are 2 main FFI camps, it seems to me(*):
>    1. I don't care about fault tolerance, I *must* access to function
>       F in library L, and to hell with the consequences of buggy
>       code.
>    2. I really care about fault tolerance ... because if I didn't, I
>       wouldn't bother with Erlang at all.
> I used to be in the first camp.  As I've developed more apps, and seen
> Erlang generic servers and supervisor trees and other Erlang/OTP
> wizardry keep my emergency 24-hour support pager completely silent,
> I'm quite firmly in the second camp.  8-)
> A raw interface with libffi would fall into the first camp.  My
> suggestion for you is to think long and hard about also supporting the
> 2nd camp, as much as possible.  Because there are plenty of us that
> would love to use special library L in an Erlang app in a *production*
> environment, but won't run the risk of using L without as many
> Erlang'ish safeguards as possible.
> For example, being able to choose whether to use the FFI via dlopen()
> 1. inside the Erlang VM, or 2. in a separate OS process (communicating
> via pipe, socket, whatever).  Preferably using the same interface.

Why can't we just start another node for all the unsafe stuff,
or even a node per library?
Some erlang glue will make it invisible to library's user,
but FFI library itself doesn't have to implement delegation of all
calls to auxiliary OS process.

More information about the erlang-questions mailing list