Differentiate synchronous and asynchronous error of an AIO operation

[Zhong Yu]

On Sat, Jun 11, 2011 at 8:51 AM, John Davis <jdavis at pcprogramming.com> wrote:
> Changing this would affect performance considerably.  The ideal case is to
> have the callback fire on the same thread that initiated, this eliminates
> context switch overhead and cache flushing.  In fact, it is this same reason
> that projects like nodejs strongly outperform multithreaded servers which
> don't center on epoll or IOCP.  The whole point is to keep everything
> running on the same core as much as possible.

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?

- Zhong Yu