Vlad Dumitrescu (EAW)
Thu Feb 20 09:51:17 CET 2003
> From: Ulf Wiger [mailto:]
> 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.
More information about the erlang-questions