> It's actually not clear poll() is a win; if you have scenario where you
> have multiple threads (possibly on an SMP system), by using signals, you
> can quickly and easily dispatch jobs to different worker threads by
> simply having different threads picking up the real-time signals.
>
> If you use poll(), you either have to do fancy locking, or you have to
> have one threads which does IPC to talk dispatch tasks to each worker
> thread, which is not ideal.
Not at all. For one thing, you can have the same thread that does the
'poll' do all the actual I/O. This works well with a send queues and receive
queues. Since non-blocking network I/O is so fast, it's almost impossible
for this I/O thread to become a bottleneck.
It depends on the application. Consider an IMAP server, with
potentially 10,000+ open connections, and each connection is going to
last for the entire mail-reading session, and will be idle most of the
time except when the user makes some requests that requires going to the
IMAP server. This is a very different access pattern than you would see
on HTTP.
If the IMAP server uses poll() to determine when the client has sent a
new IMAP request, you don't want one thread handling every single IMAP
command, since IMAP requests can take a long time to service. It's not
just non-blocking network I/O. With RT SIGIO, different threads will
automatically get dispatched for each new connection that has a new IMAP
request on it. With poll() you will need to manually dispatch the
request to a new thread.
- Ted
-
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/