[concurrency-interest] Receiving notifications from Futures

Brian Goetz brian at briangoetz.com
Mon May 18 21:17:57 EDT 2009

Its pretty easy to roll your own by overriding done() to do whatever you want 
-- signal on a Condition, put an element on a queue, counting down on a latch, 
calling a chain of listeners, etc.  While you're right that this is a feature 
that is often used, we have found that everyone has their own version of how 
this feature should work -- so the low-level solution of providing a done() 
hook enables all of them (of course with additional work.)

Manik Surtani wrote:
> All makes a lot of sense.  Is there any effort for a future JDK 
> solution?  Seems to be a feature that is often used.
> On 18 May 2009, at 18:02, Joe Bowbeer wrote:
>> On Mon, May 18, 2009 at 6:38 AM, Tim Peierls wrote:
>>     The need for completion callbacks has come up before on this list,
>>     each time with slightly different requirements. This is the first
>>     that I recall that didn't involve Callable/Runnable as well.
>>     One problem with adding methods to Future to configure a
>>     completion callback is that (in general) the Future might complete
>>     before the configuration method is called. This is not an
>>     insurmountable problem -- the configuration method could, upon
>>     noticing that the Future has already completed its work, simply
>>     call the callback directly -- but it seems a little like closing
>>     the barn door after the horse is gone.
>>     How about designing your API so that methods that return Futures
>>     optionally take a callback object?
>>     Incidentally, if the implementation of the Future returned by your
>>     methods is a subtype of FutureTask, then you might be able to
>>     implement your callbacks through the FutureTask.done() method.
>>     --tim
>>     On Mon, May 18, 2009 at 8:38 AM, Manik Surtani wrote:
>>         Hi
>>         I'm creating an API that returns Futures.  One of the things
>>         that may be useful to callers is to be notified when the
>>         Future completes, so rather than doing a future.get(), the
>>         thread can register a callback on the future and proceed with
>>         other stuff instead, being notified when the future has
>>         completed and can then call future.get() to retrieve any results.
>>         I have looked at the CompletionService API, and while this
>>         does help to some degree, it is still not something I can
>>         expose to any calling code, mainly because calling code does
>>         not register Callables on my interface.  Instead it calls
>>         methods that return Futures.
>>         I'm guessing I cannot be the first person with the need for a
>>         notifying future - how has this been achieved before?
>>         I was thinking of something like:
>>         public interface  NotifyingFuture<T> extends Future<T> {
>>           NotifyingFuture<T> notifyOnCompletion(NotifyingListener<T> l);
>>          }
>>         public interface NotifyingListener<T> {
>>          void futureCompleted(NotifyingFuture<T> f);
>>         }
>>         so that calling code could do:
>>         Future f =
>>         myAPI.masyncMethodThatReturnsFuture().notifyOnCompletion(listener);
>>         Cheers
>>         Manik
>> Also search for "custom completion task" in the April 2009 archives.  
>> And "ListenableFuture" a couple years ago.
>> I tend to approach this using custom tasks that are constructed with a 
>> reference to their listener (or completion queue) -- as Tim describes.
>> As Tim notes, one of the problems with registering a listener after 
>> the future is dispatched is that the future may complete before the 
>> listener is registered.
>> Rather than pass the listener into the method that returns the future 
>> (task handle), I tend to create my custom "completion" task first, 
>> before executing it.  This way, when the listener notifies me, I'm 
>> certain to have already seen the task instance to which it refers.  
>> Otherwise, if the future may complete before I've obtained a reference 
>> to it, trying to match-up the completion event with its cause can lead 
>> to some tricky bookkeeping .
>> Joe
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu 
>> <mailto:Concurrency-interest at cs.oswego.edu>
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> --
> Manik Surtani
> manik at jboss.org <mailto:manik at jboss.org>
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> ------------------------------------------------------------------------
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list