<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><div><br></div><div>// Björn-Egil</div><div><br></div></div><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 class="HOEnZb"><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 class="h5"><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">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>