Many thanks. Everything clarified. One last question however.
When one send a message to an actor from the outside: case 1 - a Tell ! : I believe the Actor system is used for that. As ! is actually related to the Actor. The execution context is the one of the Actor system right ? I'm really not sure. Case 2 - an Ask ? : here we get a future response. Is this future executed on the Actor system execution context or the calling thread context ? I'm asking this, because in one of the project that i have, i would like to use Actors to manage the back end of a desktop application that uses javafx 2. I'm aware already of Platform.runlater and etc.... So i'm not concern with updating the interface in this case. This is more from the interface to the actor system. *I just want to make sure on which context the communication between from a non actor to an actor system, is executed? * *Many thanks,* *M* On Thursday, February 12, 2015 at 3:32:38 PM UTC-5, Jim Hazen wrote: > > I think you're confusing two different sources of ExecutionContexts. > > The Akka runtime, as far as I know, schedules and uses non-daemon threads > internally, 100%. So all the threads supporting the ActorSystem and those > backed by actor related ExecutionContexts (i.e., context.dispatcher), > should be non-daemon. > > Now the Scala runtime and its scala.concurrent support libs are different. > scala.concurrent.ExecutionContext.Implicits exposes a default implicit > execution context defined by > http://www.scala-lang.org/api/current/#scala.concurrent.ExecutionContext$$Implicits$ > > . > > While you're performing business logic within an Actor, that business > logic may need to close over an async barrier, for example mapping results > over a future returned by the Akka ask pattern. Be careful about the > execution context used for that closure. If you use > ExecutionContext.Implicits you'll be asking for Scala's default EC. If you > ask for your actor's EC (via context.dispatcher) you'll get a different EC. > > It's well known that the Akka EC's use internal non-daemon thread pools by > default (either because there's documentation somewhere; haven't looked. > Or because this question comes up a lot and is part of a lot of youtube > tutorials). > Scala is less well documented, however I'd assume in this case they use > daemon threads. I'm guessing the Scala devs supposed that EC's designed to > support async closures shouldn't block the normal termination of the JVM. > > The Akka and Scala teams appear to have different philosophies. Hopefully > understanding which camp you're getting your ECs from, will make it easier > to understand the behavior you're seeing. > -- >>>>>>>>>> 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.
