> "If during the function execution any other dispatches are made > (directly or indirectly), they will be held until after the state of > the Agent has been changed." > > That means that if, as a result of an update, some agent sends > messages to others, they will definitely arrive after the original > agent's state has been changed.
This should help with proper ordering of updates to cells, since the actions sent by an agent will, when executed, see the updated value of the sending agent. > > The difference is, if agent A notifies B and C, and B notifies C, then > a change to A will send actions to B and C, and B will subsequently > send to C, but A's message to C and B's message to C can arrive in any > order. Once you are ok with that, you can do multithreaded reactive > programming. I think this is consistent with the cells approach because the order of notifications shouldn't matter. Each time C gets a notification it will query A and B for their values. This is true even for Stuart's original refs implementation (please correct me if I'm wrong about this). > I've often thought of providing change notification queues on the > agents themselves, letting Clojure do reactive programming right out > of the box. > This sounds like a powerful capability to have, if only to be able to trace agent changes easily for debugging and monitoring. Would this also be a way to attach side-effect-producing code to agents without concern about retries? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
