[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.