[erlang-questions] How long for the FFI EEP to go through?

[Kenneth Lundin]

On 12/11/07, Joel Reymont <joelr1@REDACTED> wrote:
> Is there an estimate for when the FFI EEP will be part of the Erlang
> distribution?
>
No, there is no estimate.
We will take a serious detailed look at the EEP , probably quite soon but
I cannot make any promise on how soon it will make it into the ordinary release.
We think it is important to have an easier way to interface external
libraries but
there are a number of problems to solve before it can be introduced as
a supported feature.

We have lived with more or less the same driver interface towards
external C-code
in more than 10 years now so I don't think we have to rush into this.

Actually one of the advantages with Erlang is that you can make robust
systems. One of the major reasons for the robustness is that there are
no or very few linked in drivers written by the application
developers.
There are several products which don't have any linkedin drivers at all
except those included in the standard distribution This makes it very
easy for us
as maintainers since when we get a core dump we know that the fault is in
our code.

So the "awkward" interface for linkedin drivers can actually be seen
as a stabilizing
factor since only those that really knows what they are doing will manage to
implement a working driver.

But as said we are very interested in improving the FFI it has been in our plans
long before this EEP but now I think the time has come to prioritize this.

Some things to be aware of :

When an Erlang process executes a FFI call which takes a long time
before it returns all other Erlang processes will also
be blocked until that call returns (in a non SMP system). In an SMP system
there are many schedulers so the call will only block one of the schedulers.
But if several  Erlang processes makes lenghty or blocking FFI calls you can
block the whole Erlang VM. This type of problems does not occur in
languages where there are no concurrency.

Many C-API's have callback functions. It would be nice if that could be handled
as well but i am not sure if we can find a generic solution for that.

I am sure there will be memory allocation issues as well, for example
cleaning up
when an Erlang process dies.

/Kenneth Erlang/OTP team , Ericsson AB