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 <sam.halli...@gmail.com>: > :-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 <sam.ha...@gmail.com> 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 <sam.ha...@gmail.com> 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 <sam.ha...@gmail.com> 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 akka-user+...@googlegroups.com. > To post to this group, send email to akka...@googlegroups.com. > 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 akka-user+...@googlegroups.com. > To post to this group, send email to akka...@googlegroups.com. > 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 akka-user+...@googlegroups.com. > To post to this group, send email to akka...@googlegroups.com. > 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 akka-user+unsubscr...@googlegroups.com. > To post to this group, send email to akka-user@googlegroups.com. > 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/groups/opt_out.
