Re: [PATCH 2.5.71-mm1] aio process hang on EINVAL

[Scot McKinley]

 > io_submit() is incapable of returning operation success notifications.

Exactly, that's why i proposed a new submission interface. ie, to
allow io_submit() to support the "always return async, even IF the
operation has ALREADY completed" paradigm, and another interface
to support the "return synchronous completions on submission"
paradigm.

 > "MAY" is far cry from "MUST".  I object strongly to requiring all
 > callers to io_submit() to be able to handle immediate completions.  In
 > my aio framework, the caller of io_submit() is not in a context where it
 > can invoke completion callbacks, since completion callbacks are not
 > required to be reentrant.

Fine (see interfaces defined above).

 > For the specific conditions under discussion, it was.  The conditions
 > were certainly extremely rare.

Yes, and we've moved past that, since there are other conditions which
are not as rare.

 > The traditional way of dealing with this is to first call the
 > synchronous nonblocking interface, retrying with the asynchronous
 > interface only when the nonblocking one indicates no progress.

Great...i am glad that we atleast agree that the interface is necessary,
tho maybe not on its makeup.

The issue i brought up (bcopy threshold), is not a non-blocking issue,
and the above is not the "traditional", nor the correct way of dealing w/
it. The app should NOT need to make multiple sys-calls to initiate
the io. By far the majority of the existly network aio api's simply
return an indication of the immediate/synchronous completion as a
return indication from a *single* submission routine. There is no
reason why we cannot, also.

Regards, -sm