> Were watchers synchronous, they would have to run post-transaction > (else a watcher action failure could cause a transaction rollback, > leaving already notified watchers confused). Being post-transaction > would mean that the refs could have been changed by another > transaction in the interim.
I've been looking at the source to make sure I understand the trade- off you're describing. In LockingTransaction, ref.notifyWatches is called immediately after ref.validate for each ref. So it seems that a watcher could be triggered with a value that then gets rolled back if a subsequent validator throws. So even with the current watcher implementation, a watcher could be called with a value that is not consistent with the actual value of the ref when the transaction is done. This doesn't seem much different from the scenario you're describing. Is this correct? > > So, to answer your question, no, watchers don't have to be agents, and > while there would be some tighter guarantees were they not, there's no > getting around the essential asynchrony of a multi-threaded system. After looking at how validators and watchers are invoked, I'm thinking the current implementation already provides both synchronous and asynchronous notification - synch notification via a validator, and asynch notification via a watcher agent. Of course, the validator isn't intended to be used as a watcher, but I wonder if you could generalize the notion of validator so that this is acceptable usage. The value provided to the validator may not represent the actual value post-transaction (due to roll-back), but this is the cost of getting synchronous notification. The watcher notification could be moved to post-transaction, with the possibility that another transaction could occur before the watcher runs, but this is the cost of asynch notification. --~--~---------~--~----~------------~-------~--~----~ 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 clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
