[erlang-questions] suggestion: NIF_D

[Paul Davis]

On Tue, Apr 20, 2010 at 11:54 AM, Robert Virding <rvirding@REDACTED> wrote:
> 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
>

Robert,

I was trying to come up with an argument or example of something that
I'd want to be able to do from a NIF that I couldn't using a port and
nothing came to mind.

The only reason it ever occurred to me to want a pid-like capability
was the availability of threads to NIF's. I had been trying to figure
out how I might embed a scripting language yet avoid potential VM dead
locks and the message passing interface would have been a nice
solution. Though I don't think this is a particularly good reason to
add such an interface, it was just one of those "so close, yet so very
far away," moments.

Paul