[concurrency-interest] Offering data to Futures

karlthepagan karlthepagan at gmail.com
Tue May 26 14:34:27 EDT 2009

On Tue, May 26, 2009 at 8:36 AM, David M. Lloyd <david.lloyd at redhat.com>wrote:

> The main distinctions are that cancel() cannot specify interruption, the
> operation may result in an IOException, there is much more flexibility in
> terms of how you wait for the result, and you may register one or more
> asynchronous notifiers.

Thanks David. I'll add your links to the list of alternatives I'm building
and see what else I've left out. I ended up doing almost exactly the same
thing with protected completion methods.

The converting future is also something I sketched out but haven't
reimplemented here. Cpu-tasks can simply nest callables in order to convert
results, but io-tasks have to filter after the results are available.

I agree with your conclusions on cancellation. I would like to allow IO
cancelation to keep the library generalized, but I'm allowing implementers
to override the default behavior and disallow interrupting with a "boolean
mayCancel(boolean)" method.

One thing I haven't decided yet is how to propagate InterruptedIOException
in the API. In the case that IO is canceled the number of bytes written
before interruption may be significant. That byte count isn't communicated
by cancel/isCanceled so I've considered either subclassing
CancellationException to hold this info or wrap it using ExecutionException.

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

More information about the Concurrency-interest mailing list