3 ms·
> Akka doesn't have lightweight threads at all. You implement a message-handling method, but it must not block on, say, a DB call, lest it block the entire thre
by saryant 13y ago
> Akka doesn't have lightweight threads at all. You implement a message-handling method, but it must not block on, say, a DB call, lest it block the entire thread it runs in. An Akka actor simply must not issue a DB call: it's as simple as that.
That's not quite true. Yes, you block that thread but this is why you configure actors with blocking calls to use their own dispatcher. For DB queries you typically put querying actors onto a thread-pool dispatcher where pool size ~= available DB connections.
Selective receive is also quite easy to implement in Akka using stash().
- arielweisberg 13y agoI 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 agoI 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 agoQuasar 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 agoWe'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.
- pron 13y agostash is not the same as selective receive at all. With selective receive you can do simple, intuitive nested receive blocks (see the Pulsar Clojure examples here: http://blog.paralleluniverse.co/post/49445260575/quasar-pulsar http://blog.paralleluniverse.co/post/49445260575/quasar-puls... or any Erlang code). And yes, you can configure Akka for certain types of usage, but it is anything but simple. We value the simplicity and intuitiveness that are at the core of Clojure and Erlang.
- saryant 13y agoI didn't say that stash() is the same, just that it's quite easy to use it to implement selective receive in Akka in combination with hot-swapping an actor's behavior with become/unbecome. We use this pattern quite successfully in our code base.