Extending Erlang

[Vlad Dumitrescu (EAW)]

> From: Ulf Wiger [mailto:etxuwig@REDACTED]

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

The idea would be that they would run inside the VM, just like a driver. The programming model would be different I think, but not so much more (the message box might be a notable exception).
 
> 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.

Somethink like that, yes.
 
> 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.

Okay, then this maybe isn't needed. 
 
> 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.)

Hmm, good point. Well, just don't allow it on VxWorks then! :-)
That was the "wildest" of the three ideas, and what I really had in mind was related to GUIs: if writing a driver to interface with a GUI, maybe it's easier to embed Erlang into a graphical application.

Best regards,
Vlad