Thanks, we're glad to hear it.
> One thing I do very often though is that I use a SettableFuture
> together with a Timer (i.e. if some action has not occurred within a
> certain time period, cancel the future). I was wondering, in a future
> release, do you think it may be useful to be able to create a
> SettableFuture which cancels itself after a certain period of time?
>
> e.g. I was thinking something like this (off the top of my head):
>
> (1) Create an interface SettableFuture which encompasses the current
> SettableFuture methods.
>
> (2) Create a new interface SettableFutureFactory which can create a
> SettableFuture with and without a timeout. e.g.:
>
> public interface SettableFutureFactory {
> <V> SettableFuture<V> create();
>
> // the "timeoutRunnable" is for the future creator to do timeout
> cleanup, not for the future user
> <V> SettableFuture<V> create(long timeout, Runnable
> timeoutRunnable);
>
> }
>
> A default implementation of the SettableFutureFactory would be passed
> a Java Timer on initialization (ugh - unfortunately there is no timer
> interface in Java). Users of the guava interface, of course, could
> also create their own implementation which passes in their own timer
> implementation.
I guess this could work with any kind of Future, not just
SettableFuture. It could be:
Futures.cancelIn(30, SECONDS, /* interrupt = */ true, executor,
future1, future2, ...);
(Timer is semi-deprecated in favor of ScheduledExecutorService, so we
might as well use that.)
If this is something people would find useful, we could take a look.
On the other hand, it's competing with get(30, SECONDS), the usual way
of setting a deadline when dealing with a Future.
Of course, this amounts to...
executor.schedule(new Runnable() { public void run() {
future.cancel(true) } }, 30, SECONDS);
...as you're probably aware from implementing most of it.
Also, I should have replied to this:
> // the "timeoutRunnable" is for the future creator to do timeout
> cleanup, not for the future user
> <V> SettableFuture<V> create(long timeout, Runnable
> timeoutRunnable);
You might want to look at using AbstractFuture instead of
SettableFuture. It provides an interruptTask() method that you can
implement to perform cleanup actions when cancel(true) is called.
I guess I could use the ScheduledExecutorService and create my own
implementation
if I did not want to use the ScheduledThreadPoolExecutor threading
model (it would be nicer
if the ScheduledExecutorService also returned a ListenableFuture :)).
On Oct 5, 6:39 pm, Chris Povirk <cpov...@google.com> wrote:
> > Futures.cancelIn(30, SECONDS, /* interrupt = */ true, executor,
> > future1, future2, ...);
>
> Of course, this amounts to...
>
> executor.schedule(new Runnable() { public void run() {
> future.cancel(true) } }, 30, SECONDS);
>
> ...as you're probably aware from implementing most of it.
>
> Also, I should have replied to this:
>
> > // the "timeoutRunnable" is for the future creator to do timeout
> > cleanup, not for the future user
> > <V> SettableFuture<V> create(long timeout, Runnable
> > timeoutRunnable);
>
> You might want to look at using AbstractFuture instead of
> SettableFuture. It provides an interruptTask() method that you can
> implement to perform cleanup actions when cancel(true) is called.
--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")