Hi Sam, the philosophy here is that if you have an ActorRef—the actor has been introduced to you—then you can send directly to it. Otherwise you will explicitly send via a gate keeper, receptionist or however you want to call it. This means that your exclusion scheme would only work reliably if A and B never expose their own identity to the outside world, they always need to set the `sender` reference to `context.parent`.
Adding an interception feature like the one you are describing would basically break Akka. Regards, Roland 24 feb 2014 kl. 14:18 skrev Sam Halliday <[email protected]>: > Thanks Roland, > > Incidentally, is it possible to create an Actor that "intercepts" all > messages sent to its children? It would appear to be a useful mechanism for > implementing Patrik's suggestion. > > e.g. > > MutualExclusionActor lives at /user/mutual > with children Actors A and B > > but any messages sent to /user/mutual/A actually go to the > MutualExclusionActor and it knows that the intended destination is Actor A. > > > On Friday, 21 February 2014 16:16:13 UTC, rkuhn wrote: > Pro tip #1: do not view the Mailbox as anything that carries semantics or > helps in your application-level concerns. A Mailbox is just an internal > implementation detail of how messages get into the Actor, and the Actor is > what you should think about. > > Pro tip #2: don’t do distributed locks (or transactions for that matter), it > does not scale. Coordination and synchronization are extremely costly and > should be considered as such; for the purposes of this tip a modern > multi-core CPU counts as distributed. Letting all messages flow through an > actor is of course a form of coordination, but modeling it as such expresses > only the core concern with no extra overhead—using a Lock within an Actor > hurts the performance of everything that happens to execute on the same > Dispatcher. > > Regards, > > Roland > > 21 feb 2014 kl. 16:57 skrev Sam Halliday <[email protected]>: > >> :-P it's pretty trivial. I don't actually have a need for it at the moment, >> it is just a thought experiment. I would probably want to reuse the mailbox >> queue ordering rules, though. That will require some jiggery pokery in the >> config. It would be interesting to profile a high load read/write Actor with >> and without a sorted queue, and with and without inherited queue ordering in >> the buffer. >> >> It just erks me that it couldn't be implemented at a framework level as a >> reusable "exclusive actors" feature, which seems like it might be useful in >> many situations and could possibly be implemented without the need for lots >> of messages going back and forth. >> >> On Friday, 21 February 2014 15:48:32 UTC, Patrik Nordwall wrote: >> >> >> >> On Fri, Feb 21, 2014 at 4:38 PM, Sam Halliday <[email protected]> wrote: >> It's not difficult in the way that it has been proposed. But I would like to >> be able to abstract it in a clean way that doesn't steal responsibility >> (from the mailbox). >> >> The only responsibility of the exclusive actor would be to keep track of >> this. >> >> >> Also, this approach demands that the message queue be ordered since "I'm >> Finished" messages are of very high priority. >> >> Not needed. It is not going to block until it receives enough Finished. It >> receives all messages and puts everything but Finished in an internal >> buffer. You can even use Stash for this. Describing it in more detail would >> take away all the fun from you. Give it a try. >> >> Cheers, >> Patrik >> >> >> >> >> On Friday, 21 February 2014 15:20:57 UTC, Alec Zorab wrote: >> Surely it's just standard application logic? The parent enforces the >> exclusivity just like any other application logic. What's the difficulty? >> >> >> On 21 February 2014 14:47, Sam Halliday <[email protected]> wrote: >> Sorry, how to know when the children have finished is not the right >> question. What I really mean is how can the exclusivity be enforced without >> introducing a lock in the delegating actor in order to allow waiting until >> the children actors are all available? >> >> To introduce a lock like this would seem to me to be something that is best >> achieved in the framework itself... would it be difficult to do such a thing? >> >> >> >> On Friday, 21 February 2014 14:37:15 UTC, Sam Halliday wrote: >> On Friday, 21 February 2014 14:28:44 UTC, Patrik Nordwall wrote: >> On Fri, Feb 21, 2014 at 2:50 PM, Sam Halliday <[email protected]> wrote: >> Hi all, >> >> Is there any concept of mutually exclusive actor paths? >> >> No >> You could build it within the exclusive actor, if you send all messages via >> that actor, including replies (or signals of completion). >> >> >> But how would I be able to tell that my child actors were actually finished >> processing the messages? >> >> >> >> >> >> >> What I mean by this is that >> >> /user/exclusive/A >> /user/exclusive/B >> >> are mutually exclusive (where A may be a round robin router of many As) >> between A and B. >> >> This would enable concepts such as read/write actors where e.g. A could be >> the reader and B the writer, with many As allowed at once (with no B message >> processing) and when B does any processing it stops messages being sent to >> the As. >> >> >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >> >>>>>>>>>> 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/groups/opt_out. >> >> >> >> -- >> >> Patrik Nordwall >> Typesafe - Reactive apps on the JVM >> Twitter: @patriknw >> >> >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >> >>>>>>>>>> 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/groups/opt_out. >> >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >> >>>>>>>>>> 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/groups/opt_out. >> >> >> >> -- >> >> Patrik Nordwall >> Typesafe - Reactive apps on the JVM >> Twitter: @patriknw >> >> >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >> >>>>>>>>>> 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/groups/opt_out. > > > > Dr. Roland Kuhn > Akka Tech Lead > Typesafe – Reactive apps on the JVM. > twitter: @rolandkuhn > > > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: http://akka.io/faq/ > >>>>>>>>>> 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/groups/opt_out. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>>>>> 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/groups/opt_out.
