There is no need to wrap the Executor Service in a* delay* because it already implements lazy-start semantics. From the *ThreadPoolExecutor* Javadoc: On-demand constructionBy default, even core threads are initially created and started only when new tasks arrive, but this can be overridden dynamically using methodprestartCoreThread()<http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html#prestartCoreThread()> or prestartAllCoreThreads()<http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html#prestartAllCoreThreads()>. You probably want to prestart threads if you construct the pool with a non-empty queue.
Also, if you constrain the design to a singleton scheduled thread pool, there is no pressing need to shut it down after all schedules are cancelled: a total of a few idle threads is deemed acceptable, especially because scheduling is either needed for the entire runtime, or not needed at all. The major issue were the abandoned schedulers, which you have solved. A more pressing concern is the size of the thread pool: with just one thread, only one task can run at a time. In practice many tasks are very short-lived and a single thread can take care of dozens of them, but some are quite long-lived, going for 10 minutes and more. Combining such tasks with the short-lived ones will result in the short-lived tasks executing on a very irregular schedule. This leads towards a configurable stateful implementation, which is against the first goal of your design. Regrettably, no obvious solutions come to mind. On Saturday, January 19, 2013 1:00:26 AM UTC+1, Adam Clements wrote: > > Hi Marko, > > I've addressed some of your concerns by re-using a single thread pool for > multiple schedule calls in the current master. The original use case was > one set of scheduled tasks running for the lifetime of my application. If > you can suggest improvements to cover other use cases with more > stopping/starting scheduled tasks and automatically cleaning up the > executor service if it's no longer needed that would be great. > > Adam Clements > > On Fri, Jan 18, 2013 at 9:50 PM, Marko Topolnik > <marko.t...@gmail.com<javascript:> > > wrote: > >> >> This looks great. I was building a couple of applications that run >>> periodic tasks/services on top of quartzite, but I'll definitely play with >>> this. Much nicer scheduling syntax, and the lack of a single stateful >>> scheduler feels much more Clojurian (and cleaner, too). >>> >> >> Behind the apparent elegance is a design that could be wasteful with >> system resources, starting another thread with each invocation of * >> schedule* and leaving the executor service running after the future is >> cancelled. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com<javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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 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
