Concurrent beam? + Erlux
Fri Mar 7 11:10:56 CET 2003
Luke Gorrie wrote:
> Quite often the "the Erlang emulator doesn't exploit SMP" beef comes
> up, and it seems like doing a full-blown parallel Pekka-and-Tony-style
> emulator isn't on the cards in the near future.
> So what I wondered was, in Erlang style, might it be easier to write a
> concurrent emulator rather than a parallel one, with one thread per
> logically concurrent activity?
> For example, one thread executes erlang processes, one garbage
> collects, one does I/O, etc?
> Just a thought. Lack of SMP doesn't actually bother me in practice.
Some random comments :-)
The combination Executing-erlang-processes and garbage-collection is a
tricky one. The simplicity in our (Pekka-Tony) approach made it, the
garbage-collect at the same time as running other processes, trivial.
One nice thing in our implementation was the abillity to run erlang
processes in separate "kernel" threads or running them in the scheduler
thread pool. That meant you could dispatch a process running free until
you decided you join the "normal" scheduling again.
The io/process pair also mean that you have to take care of the case
when io is to be delivered from a driver to a running process. This
makes the driver interface a bit slower (different anyway). In our
implementation we made up a new task structure that handled both
processes and ports in the same way. You could even add your own C-tasks.
The main thing to do with the emulator in any case is to make the
emulator fully reentrant and threadsafe. For example we implemented all
process affecting bifs with async signals (like process_info, link ...)
I have just started a project erlux that will run Erlang on top of the
Linux kernel (without user space - well you may start a user space
process if you like). This will be a patch to the kernel.org kernel
replacing the init process with the emulator loop, but not leaving the
kernel space. When running such a beast a SMP system will be useless
unless we can run the scheduler in multiple threads.
More information about the erlang-questions