Re:No More Callbacks: 10,000 Actors, 10,000 Threads, 10,000 ...
by pron on Wednesday October 16, 2013 @12:43PM
(#6560652)
I agree. That's why Quasar starts by providing true lightweight threads - you can block, wait on conditions - whatever. Only, you can have millions of those.
On top of these fibers, Quasar gives you Go-like channels and/or Erlang-like actors (I say Erlang like because they follow the Erlang model closely: you pull messages rather than implement message callbacks, they have selective receive etc.)
Re:No More Callbacks: 10,000 Actors, 10,000 Threads, 10,000 ...
by rdtsc on Wednesday October 16, 2013 @01:18PM
(#6560844)
Quasar looks very cool. How does pre-emption work? I know Erlang's VM count an actors' "reductions" -- bytecode instruction and after a certain number preempts that actor and lets other run. How does that work in Quasar? Does an actor have to explicitly yield, sleep, do IO or run receive?
Re:No More Callbacks: 10,000 Actors, 10,000 Threads, 10,000 ...
by pron on Wednesday October 16, 2013 @01:32PM
(#6560944)
We've experimented with reduction-based preemption but saw no perceivable performance benefit (you can look at the Fiber class code and see them commented out). We might bring it back if we find a good use for it.
Re:No More Callbacks: 10,000 Actors, 10,000 Threads, 10,000 ...
by lmm on Thursday October 17, 2013 @08:32AM
(#6564903)
Does that mean this system is inappropriate for CPU-bound tasks?
Re:No More Callbacks: 10,000 Actors, 10,000 Threads, 10,000 ...
by pron on Thursday October 17, 2013 @08:37AM
(#6564925)
The spaceships demo is very much CPU bound.
But, at least for the time being I wouldn't run a long-running, CPU heavy computation in a fiber, but in a plain thread. Fibers work best when they block often.
I shouldn't have to define extra actors or figure out thread pool concurrency levels to do blocking operations like lock acquisition, waiting on conditions, IO etc. A framework that that doesn't allow that adds zero value to me because I am not willing to ask others to reason about that sort of thing.
Not having that kind of transparency makes it difficult and dangerous to convert existing code bases that use traditional concurrency primitives.
I would like to have thousands or millions of actors, but for now I am stuck going to 1:1 with threads.