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"
> "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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/