[concurrency-interest] Receiving notifications from Futures

Joe Bowbeer joe.bowbeer at gmail.com
Mon May 18 13:02:17 EDT 2009


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090518/601cd499/attachment.html>


More information about the Concurrency-interest mailing list