Well, even though I've written embedded device drivers, operating system device drivers, and Ruby "drivers", all in C, and Java JNI code in C++, I found the Erlang model of linked-in drivers to be more frustrating and finicky than all the others put together (though I believe the Perl native interface has them all beat, from what I read). I think this frustration may be in large part due to the documentation, which is not always clear and understandable. I am sure once I have written many Linked-in Drivers I will wonder what all the fuss I made was about, but the first ones I found a bit of a pain to get going.<br>
<br><div class="gmail_quote">On Tue, May 27, 2008 at 12:27 AM, Vance Shipley <<a href="mailto:vances@motivity.ca">vances@motivity.ca</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Mon, May 26, 2008 at 09:37:52PM +0200, Joe Armstrong wrote:<br>
}      - Do the components run on the same machine?<br>
}      - Is a bug in one component allowed to crash the other component<br>
}      - can we upgrade the components without interrupting the service?<br>
<br>
</div>I have used a number of methods to write "drivers" for third party<br>
libraries with C APIs.  First there was the Interface Generator (IG)<br>
which was included in OTP long ago.  Later I used erl_interface and<br>
once ei appeared wrote new drivers with that.  The first linked in<br>
driver I wrote was static but now I write dynamically loadable linked<br>
in drivers.  Most of these make use of the thread pool.<br>
<br>
I never really understood the dire warnings about bugs in the linked<br>
in driver crashing the emulator.  In my systems the driver was an<br>
integral part of the system and if it crashed it was catastrophic so<br>
restarting the emulator was the correct action.  Properly configured<br>
embedded systems handle the recovery.<br>
<br>
When using erl_interface/ei the driver is in a seperate OS process<br>
acting as a "C Node" and interfacing using normal Erlang distribution<br>
protocol.  Here if the driver crashes the Erlang code simply sees a<br>
node become unavailable (i.e. {nodedown, Node}).  This behaviour may<br>
well be more appropriate for some applications.  My thinking is that<br>
if I put my efforts into an effecient and  reliable linked in driver<br>
I always have the option of dedicating a node to running the driver<br>
and use it in the same way as as a C Node.  It may be a bit more<br>
heavy weight approach but it has the advantages of being a real node.<br>
A C Node doesn't behave exactly like an Erlang node.<br>
<br>
I hear many complaints that writing drivers is hard.  While I did<br>
find it hard the first time I did these things I was coding in C after<br>
all and that is harder than what I've become so used to in Erlang.<br>
The driver_entry callbacks and erl_driver API may take a bit to wrap<br>
your head around however once you have you should find that it has<br>
been made as easy as possible for you.  The emulator handles file<br>
handle events and thread completion for you and you write handlers.<br>
<br>
While all too often the first part of my projects are to write C code<br>
just to allow me to write the rest in Erlang I feel it is worth it.<br>
<font color="#888888"><br>
        -Vance<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
</div></div></blockquote></div><br>