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

[jgmyers@netscape.com (John Myers)]

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

Scot McKinley wrote:

> > The kernel could
> > even detect success during queuing if it really tried.
>
> Yes, this is also a good thing, as i mentioned in my earlier message.
> ie, if the io has ALREADY completed, return it immediately. 

io_submit() is incapable of returning operation success notifications.  
It can only return notifications of idempotent errors, since callers who 
submit multiple requests might need to call io_submit() twice to find 
out what the error was.

> Yes, the program WILL be able to handle async completions, obviously, 
> since
> it attempting aio submissions. However, it MAY also be able to handle
> synchronous/immediate completions of its aio submissions. 

"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.

Adding an optional facility to permit callers to receive immediate 
completions is a different issue.

> > So?  That is a miniscule amount of resources used by an extremely rare
> > condition.  Such a picayune optimization hardly justifies the necessary
> > increase in complexity.
>
> It may not be miniscule.

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

> As we expand the ability to do aio to network
> descriptors, the transport that we are utilizing could easily have a
> "bcopy threshold" (a bcopy thresheld, for those that don't know, is the
> threshold under which all io will be done synchronously.

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.  Not only 
does this save the cost of the (expensive when poll-based) queuing 
overhead, it can save the cost of operations required only when going 
async, such as copying the data from the stack to the heap.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3941 bytes --]