> 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/