Sounds rather involved, but an interesting example of Erlang providing the infrastructure glue to various technologies - something that it seems to be very good at. I've got a couple of linked in drivers I'd like to migrate, one of which provides an interface to various XSLT processors (Xalan-C, libxslt, Sablotron, etc) and the other which I recently started, providing a binding to Oracle via the OCI call interface. It seems to me that both would benefit from the stability improvements that should come from Native Processes. <div>
<br></div><div>There's one thing I am a little unclear on, and perhaps it's just a case of RTFM on NIFs. For linked-in drivers, you've got the outputv callback to get a direct handle to data (in an ErlIOVec) without incurring copying - I guess that NIFs already minimise the copying which is why they're fast? Also I make heavy use of the 'driver_send_term' API call, which on the SMP runtime is safe to use from an arbitrary thread. I'm hoping that this latter facility (being able to send a message to an arbitrary pid from an arbitrary worker thread) will be preserved in the new API.  </div>
<div><div><br><div class="gmail_quote">On 17 October 2011 12:43, Matthew Evans <span dir="ltr"><<a href="mailto:mattevans123@hotmail.com">mattevans123@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">




<div><div dir="ltr">Right,<br><br>In my case I have C code (drivers and an api to some hardware), Java code (some app logic and an ipc to a larger java app) and some Erlang doing ipc and running a pattern matching app.<br>
<br>What would be nice with the new NIFS is to build the C code as a collection of NIF processes, use Jinterface for Java; effectively giving the ability to split processing into "applets" all communicating via erlang ipc. The java apps could talk to the C code via an erlang message directly, we could then move work from java to erlang or visa versa.<br>
<br>I can do this now using NIFS or linked-in drivers and an erlang middleman process, but the ability to do it directly is compelling (I.e. Java to a C NIF directly using erlang ipc as opposed to Java to Erlang process to C).<br>
<br>Matt<br><br><hr>Date: Sat, 15 Oct 2011 19:37:44 +0100<div class="im"><br>Subject: Re: [erlang-questions] New NIF behavior in R15???<br></div>From: <a href="mailto:watson.timothy@gmail.com" target="_blank">watson.timothy@gmail.com</a><br>
To: <a href="mailto:mattevans123@hotmail.com" target="_blank">mattevans123@hotmail.com</a><br>CC: <a href="mailto:joelr1@gmail.com" target="_blank">joelr1@gmail.com</a>; <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><div class="im">
<br><br><div>On 15 October 2011 14:45, Matthew Evans <span dir="ltr"><<a href="mailto:mattevans123@hotmail.com" target="_blank">mattevans123@hotmail.com</a>></span> wrote: </div><div><blockquote style="border-left:1px #ccc solid;padding-left:1ex">

<div><div dir="ltr">From what I understand the new NIF features are intended to supercede the use of linked in drivers.<br><br></div></div></blockquote><div><br></div><div>Right, I apologize for the confusion. This is exactly what I was talking about - on slide deck he calls them "Native Processes" - I had forgotten that the enhancements were going to sit along side the existing NIF APIs as it's been quite some time since I saw the presentation online. </div>

</div>
                                          </div></div></div>
</blockquote></div><br></div></div>