Messages in this thread | | | Date | Wed, 17 Nov 1999 00:10:38 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: Signal driven IO |
| |
From: "David Schwartz" <davids@webmaster.com> Date: Tue, 16 Nov 1999 20:54:33 -0800
> 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/
| |