[halayli]

In lthread, a coroutine lib, (http://github.com/halayli/lthread) you can make blocking calls inside coroutines. It gives you the lightness of event-driven, the advantages of threads, and the simplicity of sequential statements. And it can scale over cores.

[jerf]

Remember, Erlang scales between machines.

Erlang's actually all about reliability. It's the secret decoder ring to its design, not the actor model or message passing, which serve as the ways it gets to reliability. (Even to some extent its syntax. Excepting comma-period-semicolon which is just dumb.) And one of the principles of Erlang is that you don't have reliability when you are running on only one set of computer hardware.

[halayli]

lthread allows you to do so by message passing.

[DanielHimmelein]

The problem with lthread is that it does not really provide blocking calls inside coroutines (you simply cannot do this with current OSes like Linux or Windows). Just take a look at the docs:

If you need to execute an expensive computation or make a blocking call inside an lthread, you can surround the block of code with lthread_compute_begin() and lthread_compute_end(), which moves the lthread into an lthread_compute_scheduler that runs in its own pthread to avoid blocking other lthreads. lthread_compute_schedulers are created when needed and they die after 60 seconds of inactivity. lthread_compute_begin() tries to pick an already created and free lthread_compute_scheduler before it creates a new one.

It just does the blocking call on its own pthread. That simply does not scale the way Erlang does.

One day there is hopefully an OS where each file, socket, device, etc. is an actor with a message queue. Then you can really be concurrent :-). Even Erlang can then be more concurrent...

[halayli]

I wrote the docs. :) . It really does provide blocking calls inside a coroutine. The coroutine can totally block on a non-socket resource (CPU calculation, disk IO in case you aren't using aio) without effecting other coroutines.

I do agree that actor models implemented at the OS level is much cleaner, but when it comes to CPU hogging sections, messages queues are not the answer.