Concurrent beam? + Erlux

[Tony Rogvall]

Luke Gorrie wrote:
> Ahoy,
> 
> 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.
> 
> Cheers,
> Luke
> 
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.

/Tony