[erlang-questions] idea: Erlang FFI: callbacks and memory management

[Alceste Scalas]

Il giorno mar, 11/12/2007 alle 23.58 +0100, Robert Virding ha scritto:
> On 11/12/2007, Alceste Scalas <alceste@REDACTED> wrote:
>         Il giorno mar, 11/12/2007 alle 13.33 +0100, Kenneth Lundin ha
>         scritto:
>         > 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.
>         
>         If there is some way to call an Erlang fun() from C (i.e. from
>         a BIF), then the problem should be mostly solved: libffi
>         allows to define "closures", i.e. to dynamically create a
>         native function that wraps a callback written in the host
>         language. [...]
> 
> Callbacks! CALLBACKS! Callbacks are the curse of the programming
> class. They should be avoided at all costs. 
> 
> If you have a callback how do you intend to get data in and out of
> them? Callbacks can't live without shared data.

It depends.  In the numerical integration example I provided, the
callback return value simply depends on its arguments (i.e. the current
time and value).  If something else is needed, it may be enclosed when
the callback fun() itself is defined.


> In which process are they to be evaluated? Everything in Erlang
> exists within a process.

I think it depends on my previous questions: is it possible to execute
an Erlang fun() from within a BIF, and get its return term?  How?
Without an answer, all the callback discussion will remain quite
abstract (IMHO).

Anyway, I think I could make one reasonable hypothesis:

        An Erlang callback is evaluated in the same process that
        performs the FFI call that causes the callback invocation.

If a library binding supports callbacks, and adds layers over low-level
FFI calls, then its documentation should explain in which processes the
callbacks are executed.


> No, the only workable Erlang way is to replace them with messages.

I don't get how it would work in practice, at least in the FFI scenario.
Since callbacks would be executed in "FFI context", i.e. from within a
BIF that cannot be preempted by the Erlang VM, they should *never*
perform blocking operations (e.g. wait for messages).

Final note (just for clarity): linked-in drivers and FFI calls are *not*
mutually exclusive at all.  You can develop a C library binding that,
internally, opens a .so file and uses erlang:port_control/3 when needed,
and performs FFI calls when it reduces the amount of glue code.  Thus,
if messaging and threading are required, the good ol' linked-in driver
API would be still available.

Regards,

alceste
-- 
Alceste Scalas <alceste@REDACTED>
CRS4 - http://www.crs4.it/