Messages in this thread | | | Date | Thu, 19 Jun 2003 15:42:56 -0700 | From | Scot McKinley <> | Subject | Re: [PATCH 2.5.71-mm1] aio process hang on EINVAL |
| |
> 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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |