4 ms·

I am really looking forward to where actor frameworks like Akka are going, but that seems like a leaky abstraction to me. I shouldn't have to define extra acto

I am really looking forward to where actor frameworks like Akka are going, but that seems like a leaky abstraction to me. 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.

pron 13y ago
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.)
- rdtsc 13y ago
  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?
  - pron 13y ago
    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.
    - lmm 13y ago
      Does that mean this system is inappropriate for CPU-bound tasks?
      - pron 13y ago
        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.

pron 13y ago

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

rdtsc 13y ago
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?
- pron 13y ago
  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.
  - lmm 13y ago
    Does that mean this system is inappropriate for CPU-bound tasks?
    - pron 13y ago
      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.