[concurrency-interest] Offering data to Futures

karlthepagan karlthepagan at gmail.com
Mon May 25 20:08:37 EDT 2009


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


More information about the Concurrency-interest mailing list