Differentiate synchronous and asynchronous error of an AIO operation

[Alan Bateman]

Zhong Yu wrote:
> :
> With Selector API, it is possible to bind a channel to a thread, i.e.
> all actions related to the channel happen on the same thread. This is
> possible because threading is the sole responsibility of the user
> code.
>
> With AIO API, this seems impossible, even with the fact that user can
> provide a customized executor.
>
> If the executor is used only for completion handlers, we can write a
> thin executor that executes tasks immediately on the calling thread,
> giving the handlers the responsibility to switch to other threads.
> Handlers can arrange to always dispatch the same channel to the same
> thread.
>
> However the javadoc implies that the executor will also be used by AIO
> library for other tasks. Then it's impossible to the executor to do
> the above trick, for it cannot distinguish completion handlers from
> other tasks, and it cannot risk to execute any given task immediately.
>
> Would it be better, if "other" tasks are dispatched by a separate,
> internal executor, leaving the user provided executor solely for
> completion handlers?
>
>   
We have a page with some implementation details [1] that may be useful 
to this discussion. With a fixed thread pool then the tasks execute a 
loop that dequeue events and dispatch directly to the completion 
handler.  These are long running tasks with no hand-off per I/O 
operation. When not using a fixed thread pool then it works a bit like 
what you are suggesting. A small pool of internal threads handles the 
I/O events then executes tasks that invoke the completion handler (so a 
task per I/O operation). The issue with calling the completion handler 
directly is that you will call it on an internal thread and so it won't 
have the expected identity. Also the size of this internal thread pool 
is only configurable via an implementation specific property.

-Alan.

[1] http://openjdk.java.net/projects/nio/resources/AsynchronousIo.html