On Mon, Sep 28, 2015 at 10:49 AM, Richard Bradley < [email protected]> wrote:
> Good point. I think you are spot on here -- this would be a minefield in > practice, even more so than occasionally forgetting not to use Futures > inside Actors. > I hadn't thought about switchable Actor behaviors. > Yaas. Requester works very well in "steady state" Actors, but often requires a little care even in simple behavior-switching ones. (Eg, the Actor starts in state A while it is booting, then moves to state B and stays there once it is ready.) I haven't even tried using it with FSM; I suspect it would be fraught. OTOH, I'll play Devil's Advocate for a minute: *any* inter-Actor communication is pretty fraught when you're dealing with a highly mode-switchable Actor, and reasoning about the interactions is never going to be easy. I'm not sure the Requester approach makes it any worse than it already is. I've wound up strictly avoiding such situations, because they seem to be a recipe for bugs. And the truth is, I've been thinking about Richard's question for some months now -- the more I play with Requester, the more I think that a built-in Actor-specific ExecutionContext would be bloody useful. Yes, it would have limitations; yes, it would drop results on the floor if the Actor dies. In all my usage, though (and Querki uses Requester *enormously* often), that's been the right answer. By now, I'm fairly comfortable putting a stake in the ground that Futures should only be used in an Actor when they are *owned* by that Actor. They should *always* execute within the Actor's receive loop; it should be impossible to run them *outside* that loop; and they *should* simply have their results dropped on the floor if the receiving Actor has died. I have yet to come up with an exception to those rules, in three years of heavy coding in this model. It's why I eventually decided that the request() function should shadow `?` -- Actors should never, ever use ask() unless it is wrapped by request(), and I've wound up wrapping all of my other Futures with loopback(). (Requester's function that essentially transforms a Future to a RequestM.) I don't understand the ExecutionContext code nearly well enough to do this myself yet, or I'd have tried it by now. (I've dug into the code with an eye towards trying a couple of times.) But I do actually believe that everything would work quite a lot better if this were the standard model, at which point Requester becomes quietly redundant. Given how many problems are caused by Futures within Actors, I think folks aren't considering this alternative seriously enough. At the very least, an easy "opt-in" way to get an implicit ExecutionContext within this Actor would, I believe, be a huge win... -- >>>>>>>>>> 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.
