Extending Erlang

Ulf Wiger <>
Thu Feb 20 09:28:33 CET 2003

On Thu, 20 Feb 2003, Vlad Dumitrescu (EAW) wrote:

>I had some thoughts buzzing in my head for the last few
>days, and I will share them with you - who knows, maybe
>they are of some interest. I amy also be plain wrong in
>some assumptions.
>I started looking seriously at drivers and how Erlang can
>be extended. A first impression is that it's unnecessarily
>complicated. And three different alternatives came up :
>- C-processes; just like C-nodes emulate Erlang nodes,
>C-processes are Erlang processes look-alikes in more ways
>than ports: they understand Erlang terms directly, they
>have a message box. The difference is that they are written
>in C and run in an OS thread. This *might* make writing C
>extensions conceptually closer to writing Erlang code.

How would these C processes be different from the C-nodes
that you have today?

In the work around multipro Erlang, I remember that there
was some brainstorming about scheduling groups and
non-Erlang processes -- e.g. a Java thread that can speak
and understand Erlang messages.

>- Dynamically added BIFs; for library-type functions, like
>for example advanced math. Current ports feel like too

Using named ports, port_control(), and the ability to build
and return an Erlang term directly in the driver routine,
you can basically create your own BIFs today. The overhead
is minimal compared to normal BIFs.

>- "Inverse plug-in" system; found no better name. What I
>refer to is that instead of loading drivers into the beam
>VM, one might embed the VM into an external application.

I guess the tricky parts would be that the Erlang VM would
have to run in its own thread, and the other application
would have every opportunity to write into the memory
controlled by Erlang. I suspect the latter prospect would
send shivers down the spine of every Erlang runtime hacker
who's had to support and debug Erlang-C combos in VxWorks
(which has no memory protection.)

Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes

More information about the erlang-questions mailing list