1
votes

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/availble 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.

1
Some rules of thumb: Prefer immutability such that you can close over state in futures and prefer to return a result only not side effect. Prefer Actors to encapsulate mutable stare which you can address with message passing. Use the Ask pattern to adapt standard futures code to Actor code.simbo1905

1 Answers

5
votes

Actors are good when you are dealing with mutable state because they encapsulate the mutable state. and allow only message-based interaction.

You can use Future to execute in a different thread. You don't have to block on a Future because Scala's Future compose. So if you have multiple Futures in your code, you don't have to wait/block for all of them to compete. For example, if your pipeline is completely non-block or asyn (e.g., Play and Spray) you can return a Future back to the client.

Futures are lightweight compared to actors because you don't need a complete actorsystem.

Here is a quote from Martin Odersky that I really like.

There is no silver bullet for all concurrency issues; the right solution depends on what one needs to achieve. Do you want to define asynchronous computations that react to events or streams of values? Or have autonomous, isolated entities communicating via messages? Or define transactions over a mutable store? Or, maybe the primary purpose of parallel execution is to increase the performance? For each of these tasks, there is an abstraction that does the job: futures, reactive streams, actors, transactional memory, or parallel collections.

So choose your abstraction based on your use case and needs.