[erlang-questions] NIFs and hooking file descriptors to Erlang-manged poll

[Daniel Goertzen]

I don't have a particular problem using a reactor thread for fds, but it is
the flow of data in the other direction, from Erlang to a thread, that
causes more friction for me.  A NIF thread can easily message an Erlang
process with enif_send(), but the opposite is harder.

Native processes easily allow for that through the message callback
(assuming you've also eliminated your thread and pushed your reactor onto
Erlang.)  Perhaps there is some alternative approach where you could attach
a pid to a pipe() and have ErlNifEnv/ERL_NIF_TERM pairs arrive at a reactor
thread through that pipe?


On Sat, Jan 31, 2015 at 10:12 AM, Björn-Egil Dahlberg <
wallentin.dahlberg@REDACTED> wrote:

> Yes native processes would probably make drivers obsolete. We don't
> exactly know what native processes will become but we could certainly
> envision a better solution than the current drivers. Ideally we would have
> a mechanism that could schedule native code flawlessly in user space but I
> don't see that happening.
>
> Now, exactly what is the problem with making a thread and handling select
> yourself? Is it perceived as worse performance or perceived as just
> cumbersome coding? Do you need the fd to interact with other Erlang ports?
>
> // Björn-Egil
>
> 2015-01-31 16:59 GMT+01:00 Jesper Louis Andersen <
> jesper.louis.andersen@REDACTED>:
>
>>
>> On Sat, Jan 31, 2015 at 4:52 PM, Daniel Goertzen <
>> daniel.goertzen@REDACTED> wrote:
>>
>>> What is the measure of control that the VM has over drivers that it
>>> would not have over native processes?  I've always interpreted native
>>> processes as being simpler and more capable than drivers but with exactly
>>> the same hazards (executing for too long, corrupting/crashing, etc).  I've
>>> worked with NIFs but not drivers; perhaps there's some obvious aspect of
>>> drivers that I've missed.
>>
>>
>> Your observation is correct. Once you have a native process API, you are
>> essentially on the path to eradicate drivers from the Erlang system by
>> making them an extension on top of native processes. Of course, there are
>> details to be hashed out, but this is a possible path to take.
>>
>> The fun thing is that this will also make the Erlang and Go runtimes a
>> bit more like each other.
>>
>>
>> --
>> J.
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150131/77b348d3/attachment.htm>