Thanks for the explanation, endre. On a different note, I'm trying to understand what happens using async boundaries. In this example on the documentation:
1. Source(List(1, 2, 3)) 2. .map(_ + 1).async 3. .map(_ * 2) 4. .to(Sink.ignore) you create two different "islands" in the flow that will be executed on different actors. What happens with parallel flows instead? Is this the correct way *broadcast ~> Flow[X].async.map(_ =>...) ~> merge* *broadcast ~> Flow[X].async.map(_ =>...) ~> merge* or *broadcast ~> Flow[X].map(_ => /*A*/...).async ~> merge* *broadcast ~> Flow[X].map(_ => /*B*/...).async ~> merge* ? I guess the second one. Am I correct in saying that A and B will be executed on two different actors, while whatever is before the broadcast and after the merge will run on another actor? The async boundary applies to whatever comes before its introduction in the flow, but does it "end" with the ~>? *1) ... ~> Flow[X].map(/*A*/...) ~> Flow[X].map(/*B*/...).async ~> ...* *2) **... ~> **Flow[X].map(/*A*/...).**async**.map(/*B*/...)~> ...* *3) **... ~> **Flow[X].map(/*A*/...).map(/*B*/...).async ~> ...* *4) **... ~> **Flow[X].map(/*A*/...).async.map(/*B*/...).async ~> ...* Please correct me If I'm wrong: 1) B runs on a different actor than the rest of the flow (including A) 2) A runs on a different actor than the rest of the flow (including B) 3) A and B run on a different actor (the same one) than the rest of the flow 4) A and B run on different actors (each one its own) than the rest of the flow Thank you again! cheers G On Thursday, 18 February 2016 13:40:52 UTC+1, drewhk wrote: > > Hi, > > Technically, these stages always run concurrently, it is just that their > scheduling happens on the same thread in a deterministic fashion. > > >> In other words, if either A or B is running, is the stream waiting for >> the result of the "current" future before processing the other branch? >> > > Only the stage is waiting, the whole stream can still progress. You can > imagine fusing as a *simulation* of the multithreaded behavior, i.e. things > are still concurrent just at a higher granularity. With fuzzing enabled > there are actual reorderings so you can see much more variation on event > sequences. > > -Endre > > >> >> >> I think maybe this has been discussed before, but I can't find a proper >> answer... >> >> Thank you! >> >> -- >> >>>>>>>>>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
