10 Jul
2004
10 Jul
'04
2:42 a.m.
Michael Ost <most(a)museresearch.com> 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