Sorry for misspelling your name in the previous email, Maatary! -- Konrad
On Thu, Feb 19, 2015 at 10:26 AM, Akka Team <[email protected]> wrote: > Hi Marty! > You do *not *have to block when using Scala futures - the model of > working with them is chaining operations. > So you'd say `(Future(3): Future[Int]).map(_ + 2).flatMap(idx => > fetch(idx): Future[X]): Future[X]`. > Each map or foreach of any operation of that kind is triggered > asynchronously once the future completes, this way you can model chains of > ops really easily. > > Of course they work very well with Actors, because you can `Future() > pipeTo sender()` etc, but I wouldn't say they're limited to this. > > In general side effecting from a Future is not a nice thing - you get into > racy cases rather quickly - when accessing shared mutable state, sure. > But sometimes it may be pretty useful to say `write(bytes): > Future[CompletedWrite]`, and the future completes once the bytes have been > written - perhaps by some existing library that you just wrapped in a > future (with a dedicated dispatcher). > You can do the same things with Actors. I like to see futures as this > "there is not value yet, but I'm getting it soon" versus Actors can be much > richer than that. > > Related: Java's Future you actually do have to query it (possibly > blocking) to ask if it has data available. This changed in Java with the > introduction of CompletableFuture which supports some async transformations. > > Hope this helps, cheers! > > -- Konrad > > On Fri, Feb 13, 2015 at 10:58 PM, Maatary Okouya <[email protected]> > wrote: > >> I'm wondering if Futures are better to be used in conjunction with Actors >> only, rather than in a program that does not use Actor. Said differently, >> is performing asynchronous computation with future something that should >> better be done within an Actors system? >> >> Here why i'm saying that: >> >> 1 - You perform a computation for which the result, would trigger some >> action that you may do in another thread. >> >> For instance, i have a long operation to determine the price of >> something, from my main thread, i decide to launch an asynchronous process >> for it. In the mean time i could be doing other thing, then when the >> response is ready/available or communicated back to me, i go on on that >> path. >> >> I can see that with actor this is handy, because you can pipe a result to >> an actor. But with a typical threading model, you can either block or .... ? >> >> 2 - Another issue, let say i need to update the age of a list of >> participant, by getting some information online. Let assume i just have one >> future for that task. Isn't closing over the participant list something >> wrong to do. Multiple thread maybe accessing that participant list at the >> same time. So making the update within the future would simply be wrong and >> in that case, we would need java concurrent collection isn't it ? >> >> Maybe i see it the wrong way, future are not meant to do side effect at >> all >> >> But in that case, fair enough, no side effect, but we still have the >> problem of getting a value back from the calling thread, which can only be >> blocking. I mean let's imagine that, the result, would help the calling >> thread, to update some data structure. How to do that update asynchronously >> without closing over that data structure somehow. >> >> I believe the call backs such as OnComplete can be use for side-effecting >> (Am it right here?) >> >> still, the call back would have to close over the data structure anyway. >> Hence i don't see how not using Actor. >> >> PS: I like actors, i'm just trying to understand better the usage of >> future without actors. I read everywhere, that one should use actor only >> when necessary that is when state need to be manage. It seems to me that >> overall, using future, without actor, always involve blocking somewhere >> down the line, if the result need to be communicated back at some point to >> the thread that initiated the asynchronous task. >> >> -- >> >>>>>>>>>> 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. >> > > > > -- > Akka Team > Typesafe - The software stack for applications that scale > Blog: letitcrash.com > Twitter: @akkateam > -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- >>>>>>>>>> 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.
