Actually, Linux's handling of signals isn't quite POSIX - skulk around in the man pages for some good reads... from the man page for sigwait:
"BUGS Signal handling in LinuxThreads departs significantly from the POSIX standard. According to the standard, ``asynchronous'' (external) signals are addressed to the whole process (the collection of all threads), which then delivers them to one particular thread. The thread that actually receives the signal is any thread that does not currently block the signal. In LinuxThreads, each thread is actually a kernel process with its own PID, so external signals are always directed to one particular thread. If, for instance, another thread is blocked in sigwait on that signal, it will not be restarted. The LinuxThreads implementation of sigwait installs dummy signal handlers for the signals in set for the duration of the wait. Since signal handlers are shared between all threads, other threads must not attach their own signal handlers to these signals, or alternatively they should all block these signals (which is recommended anyway -- see the Notes section)." So the behavior you're thinking of - defining a handler attracts signals is actually POSIX and not Linux... NPTL (RH9, coming soon to a distro near you) makes Linux more POSIX like. According to POSIX, only ONE thread should receive it. Which one is left up to the implementor. In practice, most signals generated in a thread seem to offer themselves to that thread first (probably trying to save an interprocess call), but you really can't depend upon that totally. That's why the ntop signal traps aren't too bright... just report the code and the traceback and die. Oh, and there's still other joys in all this - among which is that running gdb resets the handler for SIGPIPE, even if it's IGNed. So you IGN it and still get it! Meanwhile, until I see the traces, there's not much I can do. It's not failing for me... -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David L Kindred (Dave) Sent: Monday, August 18, 2003 3:46 PM To: [EMAIL PROTECTED] Subject: RE: [Ntop-dev] rrdPlugin and SIGPIPE (Problem Report Id: PR_Q9VTLZ) >>>>> "Burton" == Burton M Strauss, <Burton> writes: Burton> I'll look into it, but you're probably right about just Burton> using the same code. However, it's not the same situation, Burton> as the rrd plugin doesn't run a web server. The extant web Burton> server (which already has the SIGPIPE handler) is what feeds Burton> the requests into the rrd plugin. So the SIGPIPEs are being Burton> generated by some other situation. I haven't spent any time working on multi-threaded code on Linux, but a few years back did some extensive work with threads on an old version of LynxOS. In that system, any thread that defined a handler for a signal could receive an instance of that signal, even if it really didn't have anything to do with that thread. Is that same model valid here? if so, the very fact the the rrdPlugin sets a handler for SIGPIPE makes it liable to receive one, even if it doesn't make sense. Burton> Please collect and post the gdb backtraces (bt full, plus Burton> some judicious frame n and list commands). I hope to have some later this week to look at this for you, but "Real Work" is intruding too much lately. -- David L. Kindred Unix Systems & Network Administrator Telesciences, Inc. 2000 Midlantic Drive, Suite 410 Mt. Laurel, NJ 08054-1512, USA Office: +1 856 642 4184 Fax: +1 856 866 0185 Mobile: +1 609 332 6450 [EMAIL PROTECTED] www.edbtelesciences.com _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
