If the error can be determined at submissions time, it should be
returned at submission time. It is a waste for the application to have
to setup for an async completion, when the operation has *already*
failed. I think that the number of apps that would find this logic
desirable is significant enough that we should support it. *If* we
feel that enough apps would also support the "*always* return
asynchronously" methodology, then maybe we should look at conditionally
supporting both.
Actually, for the immediate return case, we should not only support
immediate return of errors, but also successful synchronous completions.
ie, libaio already calls down to the lower layer desriptor specific
code to submit the operation, and has return values for that submission.
If those return values indicate that the operation has ALREADY completed
(synchronously), it makes sense to be *able* to return that to the
application. If the application can take advantage of this synchronous
completion, it could be a nice performance win in terms of the application
not having to keep that memory reserved and not having to track the aio
operation (ie, whatever app specific context it keeps associated w/ that
operation).
There is also a precedent for async api's supporting synchronous
completions in the industry o/s' which support async io.
One question is how would the interface change to support this model.
I like the ability to support *both* methodologies. We could simply
leave the existing interface, and apply the "always return async"
semantics to it. The NEW interface could simply return an list of
io_events, like io_get_events, w/ the immediate completions.
Another possibility is to change the iocb to actually contain an
io_event, and add to it the ability to be added to a linked list.
This way we could simply return a pointer to a list of iocb's, instead
of always requiring the user to setup an array of io_events. ie, i
would prefer to only have to worry about the memory model for
*one* entity (iocb's), instead of the current *two* entities
(iocb's and io_event's). In fact, this paradigm could also be
applied to io_get_events.
Regards, -sm
John Myers wrote:
> Daniel McNeil wrote:
>
>> I prefer getting the error on io_submit.
>>
>>
> I prefer getting the error on io_getevents(). The code that handles the
> output of io_getevents() already has to handle per-operation errors.
> The only thing user space can reasonably do with errors returned by
> io_submit() is to retry or assert. Anything else would duplicate logic
> that already has to be in and is better handled by the code that handles
> the output io_getevents().
>
> io_submit() should only return errors in cases where the caller is
> obviously buggy/malicious or in cases where it is not possible to
> generate an event.
>
>
-- Scot McKinley-------------------------------------------------------- Oracle Corporation/Network Development >\\\|/< 500 Oracle Parkway, 2OP410 (o) (o) Phone:650.506.9481 Redwood Shores, CA 94065----------oOOO--(_)--OOOo-Fax :650.506.7226- 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/
This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:23 EST