<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 2:41 PM, 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 I know. You are well versed in port crafting. =)<div><br></div><div>I don't really like the idea of having third party libs directly involved in Erlangs I/O system, especially through callbacks we have no control over. I don't really like the idea of native processes either but that's beside the point.</div><div>It's little different with drivers since we have some measure of control there.</div><div><br></div><div>You pretty much spelled out how we envision NIF usage and reactiveness handling with thread pools, your own select and messaging erlang processes. That's the way to do it. We want to isolate it and mitigate problems of things we have no control over.</div><div>It's not hard to write a thread-pool-select-message-dispatch-thingy, just some tedious boiler plate, but perhaps the thread pool handling could be done simpler or at least get a helping hand from some NIF framework.</div><div>Though, I don't see such a framework being implemented by the OTP team any time soon either .. we have far more pressing stuff to deal with.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>// Björn-Egil</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-01-29 20:32 GMT+01:00 Serge Aleynikov <span dir="ltr"><<a href="mailto:serge@aleynikov.org" target="_blank">serge@aleynikov.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I understand your reasoning, though NIF (being the "most recent" successor of C API) is a much cleaner API then the marshaling part of drivers.  Having written a fair number of ports/drivers/NIFs I should say that from coding perspective, IMHO, NIFs are the easiest/cleanest to use when it comes to bringing existing C libraries with Erlang.  Consequently, I would think that adding FD event awareness to that API (possibly prior to having full-fledged native processes) would only make it more convenient to use as it would cover more possible use cases.</div><span><font color="#888888"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Serge</div></font></span><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 12:05 PM, Björn-Egil Dahlberg <span dir="ltr"><<a href="mailto:egil@erlang.org" target="_blank">egil@erlang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>On 2015-01-29 15:20, Serge Aleynikov
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div style="font-family:arial,helvetica,sans-serif">Is there a way
          to hook a file descriptor from within a NIF function to the
          select/epoll/poll loop managed by the emulator with a callback
          invoked in the "NIF-land" on activity detected on the file
          descriptor?</div>
        <div style="font-family:arial,helvetica,sans-serif"><br>
        </div>
        <div style="font-family:arial,helvetica,sans-serif">I am looking
          for similar functionality available to NIF functions that is
          available when writing drivers using driver_select() call
          (*).  More specifically, I have an eventfd file descriptor
          that I'd like to be notified about without allocating a
          separate OS thread to poll on that FD and return results by
          sending a message to a given Erlang Pid.</div>
      </div>
    </blockquote>
    <br>
    I think you have discovered why we have drivers in Erlang. This is
    exactly the use case for drivers. Normally you don't do much in a
    driver. You react to an event and transfer the binary to erlang
    space and to what should be done in Erlang. Don't try to program
    Erlang in C (like erl_interface), do it in Erlang.<br>
    <br>
    And no, we don't have native processes (in which case drivers would
    be obsolete). And no, it's not an oversight in the NIF API, not
    really. You could see native processes as an extension to NIFs but
    it is something completely different.<br>
    <br>
    In some specific cases you could transfer a fd (socket) to Erlangs
    I/O system, i.e. select/poll. See gen_tcp:connect/3,4. I know of
    projects that open fd:s in NIFs which then get transferred to
    gen_tcp in this manner.<br>
    <br>
    // Björn-Egil<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div style="font-family:arial,helvetica,sans-serif"><br>
        </div>
        <div style="font-family:arial,helvetica,sans-serif">Thanks,</div>
        <div style="font-family:arial,helvetica,sans-serif"><br>
        </div>
        <div style="font-family:arial,helvetica,sans-serif">Serge</div>
        <div style="font-family:arial,helvetica,sans-serif"><br>
        </div>
        <div style="font-family:arial,helvetica,sans-serif">(*) <a href="http://www.erlang.org/doc/man/erl_driver.html#driver_select" target="_blank">http://www.erlang.org/doc/man/erl_driver.html#driver_select</a></div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
erlang-questions mailing list
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
    </blockquote>
    <br>
  </div>

<br>_______________________________________________<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></blockquote></div><br></div></div></div></div>
<br>_______________________________________________<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></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">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></blockquote></div><br></div>