lkml.org 
[lkml]   [1999]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.049 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site