On Jan 27, 8:49 am, MikeM <michael.messini...@invista.com> wrote:
> > 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?
>
>
No, because the watchers currently use agent sends, which are held
until post-transaction.
>
> > 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.
I don't think so. Use of validators for anything other than purely-
functional validation is not going to be supported.
Rich
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
