[lkml]   [1999]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: > 15,000 Simultaneous Connections
    The API's I've seen proposed on this list have one fundamental problem:
    They do not allow two independent libraries, both linked into the same
    address space, to safely use the facility.

    The get_next_event() API has one queue for the entire process. So if
    two independent libraries both tried to use the interface, roughly half
    of the event notifications would go to the wrong library.

    POSIX async I/O has the same problem. As far as I know, there is no way
    for a library to allocate a real-time signal number in a thread-safe
    manner. If a library, say the BIND resolver, with an existing, frozen
    interface wants to be reimplemented using POSIX async I/O, it runs a
    credible risk of using the same signal as some other subsystem in the
    same program. Also, the signal notification queue can overflow, leaving
    the program in an essentially unrecoverable situation.

    A read poll may be modeled as an asynchronous read of 0 bytes.
    Unfortunately, on some systems a POSIX async read of 0 bytes completes
    immediately, which is an absolutely useless semantic. Write polls are
    generally made unnecessary by asynchronous I/O--if a program is
    interested in writing, it generally knows what it wants to write, so it
    can actually tell the kernel what that is. Unfortuanately, there are no
    async equivalents of writev() or sendfile(), so if the process wants to
    do an async sendfile() it ends up having to do the less efficient
    write-poll-followed-by-nonblocking-sendfile()-and-loop. In that case,
    one could perhaps model a write poll as an async write of 0 bytes, were
    that not to also complete immediately.

    NT has solved this whole class of problem with completion ports. They
    handle the huge-number-of-connection problem well, they handle other
    types of events, they are SMP-efficient. The concept goes back to the
    days of VMS, why do unix kernel developers have such a big case of NIH?
    These select() replacement proposals and POSIX aio have such limited
    uses. They're crap.[unhandled content-type:application/x-pkcs7-signature]
     \ /
      Last update: 2005-03-22 13:53    [W:0.019 / U:9.512 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site