[concurrency-interest] Offering data to Futures

Jed Wesley-Smith jed at atlassian.com
Wed May 27 22:30:59 EDT 2009


I realised if I am offering up that class up for public consumption I  
should probably support cancellation. I also managed to shave a  
reference off for the byte conscious.

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

cheers,
jed.

On 28/05/2009, at 11:24 AM, Jed Wesley-Smith wrote:

> 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
>
> _______________________________________________
> 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