<div dir="ltr"><div class="gmail_extra"><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>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.<br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div></div>