> this is a problem for me. > I don't see the problem yet
> My idea is to use many coroutines instead to use many threads because it is > more scalable. *nod* Consider i realize a scheduler in which i can push many coroutines. > Pratically it is a coroutines pool inside the same thread. > Yes, that is possible. The continuations are not bound to threads. > When a corotuines is blocked by a wait() instruction it is not necessary to > block the thread but it is sufficient to suspend it. > When a corotuine is suspended , it is taken another coroutine ready to be > resumed. In this way the thread is never blocked ... and the global > performance will be very hight. > > For this reason is important to instrument synchronized blocks. > Sorry, but I don't see your point yet. It's been a while since I wrote that library but... Frankly speaking I don't see the need for synchronization. The state is handled per thread and it then creates a new continuation. There is no mutation an no need for synchronization - unless your code requires it.
