[concurrency-interest] Receiving notifications from Futures

Manik Surtani manik at jboss.org
Mon May 18 19:27:48 EDT 2009

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
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090519/db2c78f0/attachment.html>

More information about the Concurrency-interest mailing list