Re: [PATCH] async poll for 2.5

[John Gardiner Myers <jgmyers@netscape.com>]

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

Benjamin LaHaise wrote:

>I suppose one way of getting the async poll code up to snuff would be to 
>cache the poll registration in the file descriptor.  Alternatively, the 
>iocb could simply persist until it is cancelled or a refire is permitted 
>(so that the event queue does not get overrun).
>
First, can you confirm that your only problem with the async poll code 
is the fact that it doesn't amortize the registration/deregistration 
cost across multiple events?

I would say that the fact that the async poll code doesn't do this 
amortization is not sufficient reason to hold up the patch.  A 
non-amortizing async poll is sufficiently useful to warrant inclusion. 
 It is conceivable that some applications will not want to amortize some 
of their poll requests.  The non-amortizing interface can later be 
extended to an amortizing one by defining an "amortize me" bit to the 
events request mask.

I don't think caching the registration in the file descriptor is a good 
idea--there can be multiple registrations against a given fd.  The 
registration should be cached close to the iocb--either in the iocb or 
in some structure that directly references the iocb.

The model for multiple-events-per-iocb I was thinking of is as follows:

Add a concept of a "partial completion".  Unlike a normal completion, 
when a partial completion event fires the iocb is not freed.  Instead 
the iocb goes into a "fired" state.

When an iocb is in the fired state, it will not generate any more 
completion events until it is "rearmed" by user space.  The method by 
which user space rearms an iocb is to be determined.  Upon rearming, the 
iocb is once again able to generate either a partial or normal 
completion.  As with submission, rearming can generate this completion 
immediately if the situation warrants.

Canceling an iocb in the rearmed state is the same as canceling an iocb 
that has never generated a completion event.  Canceling an iocb in the 
fired state returns a normal completion through the cancellation 
interface and returns a distinct error code (not 0 or -EAGAIN) to inform 
the caller that there is an outstanding event to be synchronized with.

Attempting to rearm a canceled iocb returns an error, probably -EAGAIN 
to be consistent with cancellation.



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