[linux-audio-dev] Signals and Threads
Howdy, list: Does a signal handler (like segfault, or divide by zero) run at the priority of the thread that it gets generated for? Say thread 1 is normal prio and thread 2 is SCHED_RR thread. In normal operation thread 1 can't interrupt or supersede thread 2. Does this hold if, say, thread 1 gets a SEGV signal? Does its handler wait until thread 2 is not running to do its thing? And does it get interrupted if thread 2 wakes up while the handler is working? It would seem that signal handlers use a threads priority, from scanning the web and docs, given that threads have their own signal masks and handlers. But perhaps one of you knows this stuff off the top of your head? I want to improve how our system reacts to a crash, but I'm concerned that the real time audio processing thread will keep the signal handler from reacting promptly. I'm running Linux kernel 2.4.19 with glibc 2.3.2 which provides the libpthread implementation we use to create threads. Thanks in advance for any help... mo = Michael Ost, Software Architect Muse Research, Inc. [EMAIL PROTECTED] PS: moderator, I tried to remove a similar message sent from another email account, but the 'remove' code didn't work.
Re: [linux-audio-dev] Signals and Threads
Michael Ost [EMAIL PROTECTED] writes: Does a signal handler (like segfault, or divide by zero) run at the priority of the thread that it gets generated for? Those signals in particular are defined by POSIX to be synchronous, meaning they should be delivered to the thread creating them. Thus the signal context would run at the same priority as the affected thread. Say thread 1 is normal prio and thread 2 is SCHED_RR thread. In normal operation thread 1 can't interrupt or supersede thread 2. Does this hold if, say, thread 1 gets a SEGV signal? Since thread 1 was running, thread 2 must not have been (unless you have a multiprocessor system). Therefore the signal will be delivered immediately at normal priority. Does its handler wait until thread 2 is not running to do its thing? It was not running, though it could at any time... And does it get interrupted if thread 2 wakes up while the handler is working? Yes. It would seem that signal handlers use a threads priority, from scanning the web and docs, given that threads have their own signal masks and handlers. But perhaps one of you knows this stuff off the top of your head? What I don't know for sure is how accurately various Linux kernels implement the standard. I want to improve how our system reacts to a crash, but I'm concerned that the real time audio processing thread will keep the signal handler from reacting promptly. Only if it's using up all the CPU, in which case your system is hung, anyway. :-) -- joq