On Tue, Apr 9, 2013 at 5:00 PM, Timothy Washington <twash...@gmail.com>wrote: > > Now, this works, but I'm always open to a better idea. In clojure-land, 1) > there's a thread constantly checking for new events on the list and 2) > there will be a thread of execution for each eventID. So I'm trying to come > up with the best data and functional pattern to handle all this. I'm not > sure a plain-jane Clojure list does the trick. >
If you're polling for new events on the list, then you might want to use LinkedBlockingQueue. Or perhaps an agent: (def event-agent (agent initial-agt-contents)) (defn -pushEvent [event] (send event-agent event-handler event)) (defn event-handler [agt-contents event] ...) The event handler can keep track of any stateful stuff in agt-contents; whatever it returns will be agt-contents the next time it's invoked. For example (def event-agent (agent 0) (defn -pushEvent [event] (send event-agent event-handler event)) (defn event-handler [event-count event] (logger/log! (extract-log-details-from-event event)) (inc event-count)) will result in @event-agent evaluating to the number of events handled thus far, increasing over time, while some logger is triggered to log each event as it arrives. -- -- 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 Note that posts from new members are moderated - please be patient with your first post. 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
