Messages in this thread | | | Date | Mon, 15 Nov 1999 20:29:09 -0800 | From | Dan Kegel <> | Subject | Re: Signal driven IO |
| |
Don Howard <dhoward@multitude.com> wrote: > ... The accept() thread sets up async io on the socket and > assigns that socket to one of the woker threads via F_SETOWN > When I execute the program, I see SIGIO being delivered to the worker > thread, rather than the RT signal that I requested. > Is this a bug with my code, the kernel, or is it a just a feature > that I didn't expect?
> [Accept thread] > fcntl (newsock, F_SETOWN, SOME_WORKER_PID); // Assign the new > // connetion to a worker. > fcntl (newsock, F_SETSIG, SOME_RT_SIG); > fcntl (newsock, F_SETFL, fcntl(F_GETFL) | O_NONBLOCK | O_ASYNC); > > [Worker thread] > sigblock (SOME_RT_SIG); > while (1) { > sigwaitinf ()
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. So you should be blocking SIGIO as well, and if sigwaitinf gets it, have it clear the queue and call poll() once. See http://www.kegel.com/c10k.html#sigio for a few notes.
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
-- (The above is just my personal opinion; I don't speak for my employer, except on the occasional talk show.)
- 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/
| |