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

Scot McKinley
2003-06-19T22:27:55Z

> 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