[erlang-questions] cost of integrating 3rd party SW

[Edwin Fine]

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.

On Tue, May 27, 2008 at 12:27 AM, Vance Shipley <vances@REDACTED> wrote:

> On Mon, May 26, 2008 at 09:37:52PM +0200, Joe Armstrong wrote:
> }      - Do the components run on the same machine?
> }      - Is a bug in one component allowed to crash the other component
> }      - can we upgrade the components without interrupting the service?
>
> I have used a number of methods to write "drivers" for third party
> libraries with C APIs.  First there was the Interface Generator (IG)
> which was included in OTP long ago.  Later I used erl_interface and
> once ei appeared wrote new drivers with that.  The first linked in
> driver I wrote was static but now I write dynamically loadable linked
> in drivers.  Most of these make use of the thread pool.
>
> I never really understood the dire warnings about bugs in the linked
> in driver crashing the emulator.  In my systems the driver was an
> integral part of the system and if it crashed it was catastrophic so
> restarting the emulator was the correct action.  Properly configured
> embedded systems handle the recovery.
>
> When using erl_interface/ei the driver is in a seperate OS process
> acting as a "C Node" and interfacing using normal Erlang distribution
> protocol.  Here if the driver crashes the Erlang code simply sees a
> node become unavailable (i.e. {nodedown, Node}).  This behaviour may
> well be more appropriate for some applications.  My thinking is that
> if I put my efforts into an effecient and  reliable linked in driver
> I always have the option of dedicating a node to running the driver
> and use it in the same way as as a C Node.  It may be a bit more
> heavy weight approach but it has the advantages of being a real node.
> A C Node doesn't behave exactly like an Erlang node.
>
> I hear many complaints that writing drivers is hard.  While I did
> find it hard the first time I did these things I was coding in C after
> all and that is harder than what I've become so used to in Erlang.
> The driver_entry callbacks and erl_driver API may take a bit to wrap
> your head around however once you have you should find that it has
> been made as easy as possible for you.  The emulator handles file
> handle events and thread completion for you and you write handlers.
>
> While all too often the first part of my projects are to write C code
> just to allow me to write the rest in Erlang I feel it is worth it.
>
>        -Vance
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080527/e5c03b95/attachment.htm>