lkml.org 
[lkml]   [1999]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectHigh Performance I/O stuff (more)
    Date
    From
    I did research this weekend on high performance I/O.  I looked at differerent
    approaches and to me they all appear the same (I know that I will get some
    flamage for this). The two most prominent models that I saw were IO
    Completion Ports and Synchronous Events (such as the Gaurav
    http://www.cs.rice.edu/~gaurav/papers/usenix99.ps).

    I think that both of these models are basically the same. They both have
    an event queue that you pick up events from. The only way that they differ
    is in what they call an event. Completion ports take asynchronous opperations
    and queue an event when the opperation completes (hence the name). Synchronous
    events do the opposite: they queue an event when an opperation is possible
    and then the synchronous (usually, non-blocking) opperation is performed.
    From this, you can decouple and event queue from what you call an event.

    From what I can see either model will give roughly the same performance,
    as they both do roughly the same amount of work. The one benefit that seems
    to exist for the Completion Ports model is that there are fewer contex
    switches.

    Now, looking at POSIX.1b signals and signal queues and getting some
    information from Stephen Tweedie it looks like completion ports are doable
    without anything new, I think that I have decided.

    If you find an available signal, set the handler for it, the block it,
    this signal number now effectively becomes the completion port. You then
    can fcntl() a file descriptor with F_SETSIG and the signal number. Then to
    fetch the blocked signals, use sigwaitinfo(). I guess you could also use
    aio_{read,write}() and set sigevent appropriately. This actually seems
    preferable since you can then use aio_return() to find the return value
    out and use aio_cancel() to cancel the request if wanted.

    The one drawback that I see to this is that it can only really handle
    aio_{read,write}() and {read,write}()/fcntl(). Any other events such as
    thread/child deaths cannot really be worked into this scheme unless you
    could set the signal they deliver on termination.

    If you really wanted to, you could have signals delivered for the ability
    to read/write to a file descriptor and then you would have Gaurav's model.

    Basically, unless anybody can see anything wrong with this get to work
    implementing!

    -jason


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:54    [W:0.020 / U:30.436 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site