ErlInterface

[Kent Boortz]

"Vlad Dumitrescu" <vlad_dumitrescu@REDACTED> writes:
> This is not an answer, but it's related: There is no "EI User Guide" in the
> documentation, the link is dead and also no such file seems to exist.
> 
> Maybe the User Guide would have helped Rick (and us others) to better
> understand what's going on.

The plan was to include a new "EI User Guide" in R9C and clarify the
difference between using the old erl_interface library and the newer
ei library. Unfortunately this user guide isn't written yet,

Vance Shipley <vances@REDACTED> writes:
> I'm getting used to deprecated C language interfaces.  I started
> out using IG, then erl_interface and now ei.  Someday we'll drop
> ei in favour of UBF or whatever is next.        :)

It is hard to get a clean nice interface from C with an abstraction
level that makes it efficient enough and yet hide the details about
the internal representations or the external format. But we haven't
given up on trying, that is why the C interface is likely to change
again ;-)

Seriously, when adding the connection part to ei it was a mistake to
just clone the erl_interface functions. This is why ei isn't
reentrant, ei_connect_init() and ei_connect() should have returned
node objects and connection objects that was passed on to the other
functions that handle the connection. Now there is shared data that
map between file descriptors and node/connection data. This data is
protected with thread locking. We will work on making ei reentrant.

Someone has to correct me if I say this wrong. The ei library is
thread safe but not reentrant, i.e. you can safely set up and use
connections from different threads but you can't safely call
ei_connect() from a signal handler. Erl_interface uses ei for the
connection handling so the erl_interface library should be thread
safe as well.

Rick Pettit <rpettit@REDACTED> writes:
> Another question is why some calls internally call erl_err_quit() instead of
> returning an error. Granted, most of those errors (if not all) will stop the
> library routine in question from proceeding, but to terminate the calling
> process seems a bit extreme.

Historical reasons. There may be programs out there that depends on
this behavior. Ei don't call exit,

kent