Subject: Re: [linux-audio-dev] Signals and Threads
From: Jack O'Quin (joq_AT_io.com)
Date: Sat Jul 10 2004 - 07:32:27 EEST
Michael Ost <most_AT_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
This archive was generated by hypermail 2b28 : Sat Jul 10 2004 - 07:38:24 EEST