[concurrency-interest] Offering data to Futures

Jed Wesley-Smith jed at atlassian.com
Wed May 27 21:24:50 EDT 2009


I have a similar class that implements Future but does not take a  
Runnable/Callable like FutureTask. I realised it didn't support  
exceptions (I didn't need it at the time) so I added that this morning.

It is considerably simpler in design to your version. It simply uses  
an AtomicReference and a CountDownLatch to co-ordinate updates and  
waiting.

To do the onDone/onFail/onCancel stuff I'd probably use another class  
that decorates this one and pass handlers rather than using sub- 
classing.

http://labs.atlassian.com/source/browse/CONCURRENT/trunk/src/main/java/com/atlassian/util/concurrent/SettableFuture.java?r=2413

cheers,
jed.

On 26/05/2009, at 10:08 AM, karlthepagan wrote:

> As a followup to last week's great discussion of FutureTask.done()  
> callbacks I'd like to ask if anyone else has rolled their own  
> "remote Future" implementation or something which interfaces with a  
> messaging library? I found one attribute of FutureTask.Sync is that  
> it protects innerSet and innerSetException from being set outside of  
> innerRun so as far as I imagined it cannot be extend to provide a  
> receiver for messages.
>
> I find the Future API so comfortable that I wanted to apply it to  
> other IO-bound and remote tasks rather than simply CPU-bound tasks,  
> but consuming a thread per request isn't usually desirable. For  
> example the Jersey HTTP client API makes use of futures to solve an  
> IO-bound task:
> http://www.nabble.com/HTTP-Client-API--was%3A-Jersey-client-side-API--td22289451.html
>
>
> With that in mind here is an API inspired by a few iterations of  
> this problem:
>
> public interface MessageFuture<V> extends Future<V> {
>     boolean offer(V data);
>     boolean offerException(Throwable t);
> }
>
>
> I have a possibly naive implementation up on GoogleCode, but  
> feedback is welcome:
> https://karlthepagan.googlecode.com/svn/trunk/MessageFuture/
>
> After providing something that could meet the needs of Jersey and/or  
> Grizzly http-client I would like to move this in the direction of  
> simplifying the interface to message-based systems without creating  
> additional message handles when they are not solicited (i.e.  
> submit() would create a Future task but execute() would not).
>
>
> -karl
> _______________________________________________
> 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