Hi All, Thanks for the great replies. John, the self-send-off idea is terrific and hadn't occurred to me. I'll be using a variant of what you proposed.
Garth On Sun, Oct 11, 2009 at 10:29 PM, John Harrop <jharrop...@gmail.com> wrote: > On Sun, Oct 11, 2009 at 5:28 PM, Raoul Duke <rao...@gmail.com> wrote: > >> >> will actors actually do the queued function w/in a reasonable >> >> timeframe? i don't think there are any guarantees of it so if one is >> >> hoping to get really nicely periodic behaviour... just curious because >> >> i'd thought of using agents for periodic stuff, too. >> > >> > In practice, they seem to. >> >> it seems like a common thing people try to do in Clojure e.g. random >> link >> http://github.com/fffej/ClojureProjects/blob/33ef9f0d1c67821658122273321e0a403486374b/misc/uk/co/fatvat/flock.clj >> >> so, can anybody "official" say if this use case is / will be >> explicitly kept in mind for agent implementation? >> >> thanks :) > > > Agents are for asynchronous, sequential state changes. Which means there is > a guarantee that a change to an actor will be processed before its next > action (but after its current one). There's no guarantee of promptness of > getting to any particular message, but the evidence is that it's on a > best-effort basis. The system's semantics won't change, then, but it may get > slow if the system is heavily loaded (CPU, I/O contention, RAM/pagefile, > whatever is relevant) or the actor tasks are long-running. > > If you want one with the ability to interrupt/abort the current task you'll > need to roll your own using threads and interrupt (I wouldn't recommend > interrupting an agent thread, even if the agent task catches > InterruptedException and returns; if the interrupt hits at the wrong moment > between one job's catch and the next's try, you'll get at best agent errors > (an InterruptedException in the error queue) and at worst a crashed agent > thread. (Finding the thread an agent is using is possible but nontrivial; > the same agent may be using a different thread on successive sends, so it's > really the agent task and not the agent that has a thread. A long-running > task could start with a reset! of an atom to (Thread/currentThread) to give > the code that launched it a reference to the Thread object via which to > interrupt it. Interrupting it after the task is complete may interrupt some > OTHER agent's task, never mind some other task given to the same agent.) > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
