Extending Erlang

[Shawn Pearce]

Just a quick comment, I'm sure others are familiar with this too:

When one extends the Oracle 8i or 9i database with C or C++ code
that is to be called from within a stored procedure or whatnot,
the database starts up an external program (extproc) which loads
the DLL (or shared library) and invokes the proper C function
entry point using dlsym().  Although slower, as the database must
communicate through a socket to the extproc host, the database
can ensure that the user developed software does not contain a
bug which can affect the stability of the database server itself.

I have to agree with Oracle's decision, as I see the JVM die too
often from problems with linked in JNI code (let alone stability
problems within the JVM itself).  User code cannot be trusted.

Except for extremely speed critical BIF style functions, the EVM
should only be extended by memory protected processes, for sanity's
sake.

It may be worthwhile to consider allowing shared memory between
the memory protected process and the EVM for movement of very large
binary objects, rather than copying them over a pipe.  This doesn't
protect against the extension from writing to a read-only binary,
but the performance gains may outweigh it.  (Besides of which, it
may be possible for the Erlang access library to use mprotect
to make the region read-only when the EVM has a reference to that
binary, and make it read-write only when the EVM has release the
binary.)

-- 
Shawn.

  You need more time; and you probably always will.