[erlang-questions] Erlang beginner questions

[H. Diedrich]

Welcome!
> This is exactly they type of example I'm looking for, thanks Henning!  And
> I've been thinking I should embed a scripting language like Lua for
> developers extending things without modifying underlying code, so this is a
> really great find, thanks.
>   
Be sure to check out other projects re Lua. This was really referred to 
as an example of architecture.
> Each computer has one instance of the Erlang VM running.  
You can have more, in fact, 2 might make sense and that's what I think 
might be what you want.
> Each VM can have
> many processes.  Using a linked-in driver essentially treats that C module
> as an extension of the Erlang VM itself, so if it crashes, so do all of the
> processes that are running in that VM on the individual machine.  
Right.
> Does the
> VM restart automagically, or does it require a manual restart?  
Erlang is made for the VM never to crash and it has an elaborate 
structure on how processes inside the VM restart each other and 
supervise each other. That architecture can span multiple 'nodes'. But 
when crashing, dying, exiting is talked about, in general you want it 
all to happen 'gracefully' and not have to restart the entire VM.

BUT you could decide to have your C library linked-in to one Erlang VM, 
with very thin Erlang code on top, that talks to another VM (node) and 
of that first one you make sure comes up automatically if the whole VM 
crashes, e.g. due to the C stuff, while the second is your main Erlang node.
> A port driver, on the other hand, is treated as a separate node.  If it
> crashes, it is contained within that node.  It is slightly slower than a
> linked-in driver though.  Is it fast enough to implement many messages per
> second back & forth? 
Absolutely.
> By saying it's not quite as fast as a function call
> I'm assuming you mean a linked-in driver call, right?
Yes. But also in Erlang proper, sending messages is a tad slower than 
function calls.
>   Essentially a port
> driver is probably best for implementing hardcore math many times per
> second, right?
>   
Many times per second would be "low frequency" and so, especially if you 
must realistically expect crashes, yes.

Henning