Ah, thanks for the tip. I have now released 0.1.2 which is unchanged apart from this fix (not leaking ExecutorServices) and improved documentation.
For the single threaded point, I have added in to the documentation that tasks with a non-trivial running time should fire futures in order to avoid affecting subsequent scheduled tasks, which I think is a reasonable restriction to make given the resulting simplicity. Thanks again for the useful feedback. Adam On 19 Jan 2013 09:53, "Marko Topolnik" <marko.topol...@gmail.com> wrote: > 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>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 >>> 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 >>> For more options, visit this group at >>> http://groups.google.com/**group/clojure?hl=en<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 -- 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
