I think you are looking at it from a very simplistic perspective without taking into account many details that happen behind the scene, people tend to use concurrent execution wrong where at the end of the day you still have a finite set of processors -and small amount- so concurrent IMHO or at least how concurrency is mostly used, it tends to overwhelm and exhaust resources instead of making things faster, Actors -using my own wording and not the documentation which is great and would had answered your concerns and more- are merely mailboxes, and thread pools will decide which mailbox is going to be processed next.
So if you think of Actors as an analogy of synchronous and blocking your analogy is completely wrong, it is serialized yes to avoid context switching, but as a single serialized unit of execution once it starts, but it is asynchronous because delivering the message to a mailbox and processing are two completely separated operation, I tend to recommend people to read the 1st two or three parts of Akka reference documentation: http://doc.akka.io/docs/akka/2.4.0/scala.html Akka is not the only framework that follows such asynchronous processing, look at Vert.x and Vert.x Web for example, which is simpler and similar, though not as rich and limiting in serialization of their message passing. Hope that helps, Guido. On Monday, November 9, 2015 at 9:02:08 PM UTC, Stuart Reynolds wrote: > > In a highly concurrent system, it seems to me that the major benefit of > using Akka is not in allowing concurrent computation (Futures work more > simply), but in ensuring correct execution of things that should not happen > concurrently (e.g. serializing access to state). > (from reading this: Don't use Actors for concurrency > <https://www.chrisstucchio.com/blog/2013/actors_vs_futures.html>). > > Is this a fair way to think about Akka? > > Suppose I build a stateless webserver, what benefits (if any) does Akka > provide in its implementation? > > For example, for Spray <http://spray.io/> HTTP servers, spray encourages > the use of Actors in routing requests. That is, a single actor exclusively > blocks the routing of other requests until either, the request completes or > a child actor is created to manage this. Why does Akka help here? It seems > to me that it encourages blocking for no benefit -- since routing is > typically a stateless operation, what's the rationale in making this > operation an actor? > > Thanks, > - Stuart > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
