[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.055 / U:9.024 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site