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

[Björn-Egil Dahlberg]

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/4e1b9919/attachment.htm>