Messages in this thread | | | Date | Tue, 15 Oct 2002 16:26:59 -0700 | From | John Gardiner Myers <> | Subject | Re: [PATCH] async poll for 2.5 |
| |
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.
[unhandled content-type:application/x-pkcs7-signature] | |