<div dir="ltr">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.<div><br></div><div>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?</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 31, 2015 at 10:12 AM, Björn-Egil Dahlberg <span dir="ltr"><<a href="mailto:wallentin.dahlberg@gmail.com" target="_blank">wallentin.dahlberg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>// Björn-Egil</div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">2015-01-31 16:59 GMT+01:00 Jesper Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>></span>:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><span><br><div class="gmail_quote">On Sat, Jan 31, 2015 at 4:52 PM, Daniel Goertzen <span dir="ltr"><<a href="mailto:daniel.goertzen@gmail.com" target="_blank">daniel.goertzen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.</blockquote></div><br></span>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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The fun thing is that this will also make the Erlang and Go runtimes a bit more like each other.<span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>J.</div>
</font></span></div></div>
<br></div></div><span class="">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>