Moving CompletionHandler to java.util.concurrent

[Alan Bateman]

Gili wrote:
> :
> Okay, so why did the team decide against this approach? What problems are
> associated with it?
>   
If you want a callback (or completion handler) to be invoked when the 
I/O completes then you don't need a Future - just specify the completion 
handler when initiating the I/O operation and don't create any objects 
that could potentially be tenured. In terms of usage then it would be 
strange to wait/poll for a result and at the same time be notified when 
the I/O completes. In terms of performance it works well to dispatch 
directly to the completion handler on the thread that is handling the 
I/O event. If you are setting the completion handler after the fact then 
it may require a slow-path wakeup of an I/O thread to ensure that the 
completion handler is invoked on a thread with the correct identity 
(unlike thread pools, the threads may be blocked waiting on I/O events 
rather than work queues).

> :
> I don't understand what you mean here. How can one wrap a channel to achieve
> the behavior I'm asking for?
>   
It shouldn't be too hard to create a class that wraps a channel and 
defines I/O methods that return "ListeningFuture"-like object. The 
implementation will use the I/O methods that specify a completion 
handler so that it is notified when the I/O completes. That notification 
can be used to dispatch to the listeners, set the Future results, etc. 
The only complication is listeners that are set after the I/O completes. 
In that case it doesn't have a way to ensure that the listeners are 
invoked on a thread with the expected identity.

-Alan.