Messages in this thread | | | Date | Tue, 16 Nov 1999 14:19:43 +0000 (PDT) | From | Don Howard <> | Subject | Re: Signal driven IO |
| |
On Mon, 15 Nov 1999, Dan Kegel wrote:
> Regardless of whether there's a bug, you might need to handle SIGIO. > It's sent if the RT queue overflows, and tells you to clear the > signal queue and fall back to normal poll() processing for a moment.
Oh - I did handle SIGIO (I forgot to show that in my pseudo code). The handler logs a warning message about signal queue overflow.
> So you should be blocking SIGIO as well, and if sigwaitinf gets it, > have it clear the queue and call poll() once.
Is SIGIO somehow guaranteed to be queued? The reason the kernel sends SIGIO is because there is no more room to queue signals, right?
Also, the wouldn't it be better to _lose_ an event (and possibly leave a connection in limbo) than to spend the time to poll 10k+ sockets? Remember, you are going to be _heavily_ loaded before you start seeing SIGIO.
I understand that each thread has it's own signal queue and that you can tune the size of the signal queue via /proc/sys/kernel/rtsig-max. Is that correct? If so, then I can consider the SIGIO as a warning that I need to configure the server with more queue space, or get faster hardware. What do you think?
> See http://www.kegel.com/c10k.html#sigio for a few notes.
This is an excellent reference (I read it several times before starting this project). Thanks for putting it up.
> I'm fuzzy on the details of who gets sent the SIGIO in a > multithreaded program, though, or how well this works > in programs that use several realtime signals for > different groups of fd's. sct? > - Dan
I'm using only one RT signal. Each thread seems to have it's own signal queue. In the tests that I've done, the thread that F_SETOWN's the socket is the recipient of all IO-related signals for that socket. (Which is you would expect with Linux's non-posix thread/signal behavior)
-- -Don dhoward@pobox.com
- 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/
| |