[erlang-questions] NIFs and hooking file descriptors to Erlang-manged poll
Sat Jan 31 17:12:10 CET 2015
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
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?
2015-01-31 16:59 GMT+01:00 Jesper Louis Andersen <
> 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.
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions