[erlang-questions] suggestion: NIF_D

[Robert Virding]

On 20 April 2010 14:46, Paul Davis <paul.joseph.davis@REDACTED> wrote:
> Ulf,
>
> Two issues come to mind. NIF execution ties up an entire scheduler,
> which means that embedded language environments are fairly limited in
> what they can do. The two JavaScript embeddings I know of both focus
> on use for small quickly executed scripts to serve merely as a
> convenience and/or sandbox for user code on servers.
>
> Secondly, both JavaScript interpreter embeddings use less than 1K
> lines of code each. One of the reasons I think that NIF's are so cool
> is that they really don't require a lot of code to plug in different
> libraries. So unless the D is really well integrated it most likely
> wouldn't be worth the hurdle as a user of the NIF.
>
> Two ways I can think of to make language embeddings more interesting
> would be to somehow allow NIF's to create a pid that could send and
> receive messages in a background thread or to have some sort of
> automagical dispatch to a thread pool.

Isn't this just for what you use ports, with or without linked
drivers? The port abstraction *IS* a process with which you
communicate using messages, although the process is not an erlang
process but some external process. The port_command interface tends to
hide this though.

To me this is the distinction between NIFs and ports: NIFs behave like
function calls and ports like asynchronous processes. N.B. many OTP
interfaces hide the message communication behind a function call, for
example gen_server, but the messages are still there.

Robert