I used a couple of watchers to push model updates onto the EDT in a Swing app; it 'just worked'. I haven't pushed the envelope on it but the abstraction is clear and clean IMHO.
Tom 2009/1/26 Rich Hickey <richhic...@gmail.com> > > > > On Jan 25, 4:06 pm, Stuart Sierra <the.stuart.sie...@gmail.com> wrote: > > Hi Rich, all, > > > > Ever since the new implementation of watchers I've been itching to try > > out Cells again. It worked great for agents. I ran into a snag, > > though, when I tried to make cells out of refs. Here's an example. > > > > I make two refs: > > > > (def r1 (ref 1)) > > (def r2 (ref (+ 10 @r1))) > > > > Add a watcher so that r2 gets updated whenever r1 changes: > > > > (add-watcher r1 :send (agent nil) (fn [a r] (dosync (ref-set r2 (+ > > 10 @r))))) > > > > Seems to work: > > > > (println @r1 @r2) > > ;;=> 1 11 > > (dosync (ref-set r1 2)) > > (println @r1 @r2) > > ;;=> 2 12 > > > > Unless I go too fast: > > > > (do (dosync (ref-set r1 3)) (println @r1 @r2)) > > ;;=> 3 12 > > > > And I have to wait for the watcher to catch up: > > > > (println @r1 @r2) > > ;;=> 3 13 > > > > I guess I was hoping that the watcher on a ref would be called > > synchronously in the same transaction that modified the ref. I'm not > > sure if that's possible, or even desirable. I found a way around, but > > I had to abandon watchers in the process. > > > > So I suppose my question is, do watchers have to be agents? > > > > 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. > > 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. > > I understand that makes it harder to copy synchronous single-threaded > Cells to Clojure, but I wonder if that is the right approach. I guess > what I am hoping for is for someone to re-imagine cells in a Clojure- > like way, i.e. not a stop-the-world model. > > Chouser had an interesting use-case (with watchers on agents) where > async notification made it difficult to determine when a generative > process completed. > > So, I could go back to watchers are functions, and have a set > deterministic time when they would run. For refs that would be post- > transaction. People that wanted async notification would have to send > to agents manually. > > Anyone else trying out the watcher system? Now's the time to chime in > with feedback. > > Thanks, > > 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 -~----------~----~----~----~------~----~------~--~---
