[lkml]   [2002]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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]
     \ /
      Last update: 2005-03-22 13:30    [W:0.022 / U:31.352 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site