why not both Future and CompletionHandler?

[Rémi Forax]

On 04/14/2011 06:21 PM, wolfgang.baltes wrote:
>
> On 2011-04-14 08:38, Alan Bateman wrote:
>
>
>     Sangjin Lee wrote:
>
>         Yes, I think it can come very handy if you want to add some
>         cross-cutting concerns in the completion handlers but allow
>         the end users to interact with the result via Future.
>
>         For example, suppose I build a framework/library for others
>         using the async channels (HTTP app, ssh app, etc.). I want to
>         allow my users freedom to choose between the "pull" (future)
>         and the "push" (completion handler). However, *regardless* of
>         what my end user choose to interact with the result, I want to
>         be able to inject some concerns like logging, instrumenting,
>         etc. in the form of a completion handler (can be completely
>         internal to the framework).
>
>         With the current APIs, if the user wants a future, the
>         framework cannot use the completion handler and I would need
>         to find another way to inject such logic. Or if I want to
>         retain the completion handler for the framework, then I would
>         need to create my own future objects to provide to the end
>         users. Either approach is doable, but it would be so much
>         easier if the NIO.2 APIs provide both mechanisms in a single
>         method call. My 2 cents. Thanks!
>
>     For high performance applications using completion handlers then
>     we don't want to future Future objects that won't be used. In your
>     framework/library then won't it return your own Future type anyway?
>
>     -Alan.
>
> (This is a resend with subject filled in. Sorry, but I have email 
> problems this morning.)
> Hi,
>
> I encountered a similar need. The problem I wanted to solve was that I 
> didn't want to have my main code thread wait (or block) for completion 
> of the I/O operation only to start a follow up task. I created a class
>
>    class CompletionFuture
>    extends FutureTask<V>
>    implements CompletionHandler<Integer, A>
>
> that does the trick. It's constructor takes a Callable<V> as argument. 
> The created object is a Future<V>. The CompletionFuture's (or 
> CompletionHandler's) completed(Integer, A) method essentially submits 
> itself (in its role as FutureTask) to an ExecutionService. When this 
> task is finished the get() method unblocks. The CompletionFuture's 
> failed(Integer, A) method shortcuts the task by calling the 
> setException(Throwable) method. Again, this unblocks get(), by 
> throwing the exception. Alternatively, fail could also run the task 
> using some instance field to indicate the failed condition.
>
> I can send a skeletal version of my code if desired. I am not sure 
> that this functionality is sufficiently generic to be of general 
> interest as it may need to be adopted to every specific application. 
> For example, the task could be executed by the same thread as the 
> CompletionHandler, by an ExecutionService other than the main thread, 
> or the thread pool in which the main thread runs.
>
> Wolfgang.

How do you implement cancel ?

Rémi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110414/59f44e07/attachment.html