[erlang-questions] RFC: Erlang FFI

[Denis Bilenko]

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:
http://forum.trapexit.org/viewtopic.php?p=26036&sid=39dc56963cb8e2442bef91d8a4492b12
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:
http://effi.googlecode.com/svn/trunk/examples/
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.