Where is this first man page that you're looking at? sigaction()
allows you to set the signal handler for the whole process. The only
thing you can really do per-pthread is to control the pthread's signal
mask. If you're talking sprocs then maybe you can have this control.
Michael

Steven Wong wrote:
>
> Hi,
>
> I was looking at sigaction(), and according to the man pages (for IRIX
> 6.5):
>
> The sigaction POSIX service allows for per-thread handlers to be
> installed for catching synchronous signals. It is called in a
> multithreaded process to establish thread specific actions for
> such signals.
>
> So would calling sigaction set the signal handlers for the calling
> thread? how else could you specify which thread the handler's for?
>
> Also, there is another sigaction() listed in the tech pubs library for
> IRIX 6.5, which sends signals to processes. How would you know which
> one your calling? would it depend on whether or not pthreads were
> linked?
>
> If thread-specific handlers were set up, is it possible that sending
> the SIGKILL signal to a thread (using pthread_kill()) would not kill
> the whole process?
>
> Thanks!

--
Michael A. Raymond
Core OS Scheduling Group Real-Time Lead

On Thu, 2 Oct 2003, Steven Wong wrote:

> I was looking at sigaction(), and according to the man pages (for IRIX
> 6.5):
>
> The sigaction POSIX service allows for per-thread handlers to be
> installed for catching synchronous signals. It is called in a
> multithreaded process to establish thread specific actions for
> such signals.

I'm not sure where you saw this text. It's certainly not what I
see in current 6.5.x sigaction(2) man pages. Perhaps you could
post the output of:

% showfiles -- sigaction

Which should tell you where all the files with "sigaction" in their
name (in particulr the man page) are coming from. On my machine:

f 14661 8046 dev.man.irix_lib usr/share/catman/p_man/cat2/standard/sigaction.z

It would be worth following that up with something like:

% versions dev.man.irix_lib

Which for me yields (from 6.5.22m which we're currently working on):

I dev 09/10/2003 Development System, 7.3.1.2
I dev.man 09/10/2003 Development Documentation, 7.3.1.2
I dev.man.irix_lib 09/10/2003 Development Environment IRIX Manual Pages

> So would calling sigaction set the signal handlers for the calling
> thread? how else could you specify which thread the handler's for?

The verbage you included above seems grossly incorrect. It is
not possible to specify a signal handler for an individual thread,
signal handler registrations are a property of the process as a whole.

For Pthreaded programs, to steer a particular signal to an individual
Pthread requires you to both register the signal handler (i.e. via
sigaction(2)) and to use pthread_sigmask(3P) to mask the signal
in question for all of the non-interested Pthreads. That is you
enable signal catching for the whole process, then mask it away
from all the threads which shouldn't receive it.

> Also, there is another sigaction() listed in the tech pubs library for
> IRIX 6.5, which sends signals to processes. How would you know which
> one your calling? would it depend on whether or not pthreads were
> linked?

sigaction(2) is a system call (that's why it's in section 2 of the
man pages), and as such there is only one possible version being
picked up. It is true that a Pthreaded program's libraries intercept
the sigaction(2) system call and twiddle a few bits, but from your
program's perspective there should be no functional difference
between a non-threaded and Pthreaded program's behavior with sigaction(2).

That said, the version on Techpubs is correct. I don't think there
are multiple library versions on your system, just an incredibly
outdated and incorrect (ot at least misleading) man page.

> If thread-specific handlers were set up, is it possible that sending
> the SIGKILL signal to a thread (using pthread_kill()) would not kill
> the whole process?

Well, ignoring the thread-specific discussion above, SIGKILL cannot
be blocked nor caught (this is enforced both by the kernel and for
sanity reasons by libc/libpthread), and in any case will always cause
the entire process to be killed as it is the kernel which handles
the SIGKILL on behalf of the process.

I hope that helps,
Brent Casavant

--
Brent Casavant bcasavan@sgi.com Forget bright-eyed and
Operating System Engineer http://www.sgi.com/ bushy-tailed; I'm red-
Silicon Graphics, Inc. 44.8562N 93.1355W 860F eyed and bushy-haired.

Thanks for the replies guys,

Actually the man pages I was referring to were both found on techpubs.
If you goto the techpubs library and enter just sigaction as the
search term, the first result is sigaction(3thr) and the second is
sigaction(2).

sigaction(3thr) is the one that says its for per-thread handlers.

I guess I am misunderstanding what its saying. Its just that I am
looking at some old code that uses pthread_kill() (with SIGKILL) to
kill child threads. I can't figure out how it works if SIGKILL kills
the whole process. I thought that the threads may have their own
signal handlers that somehow prevented the whole process from dying, (
or possibly the main thread would be catching SIGCHLD signals, though
I'm not sure if SIGCHLD signals are generated from events from child
processes, or child threads or either )

On Fri, 3 Oct 2003, Steven Wong wrote:

> Actually the man pages I was referring to were both found on techpubs.
> If you goto the techpubs library and enter just sigaction as the
> search term, the first result is sigaction(3thr) and the second is
> sigaction(2).
>
> sigaction(3thr) is the one that says its for per-thread handlers.

Hmm, sigaction(3thr) is part of dce.man.manpages. I'm not sure
why the Distributed Computing Environment would mess with sigaction.
But my cursory reading of the DCE code seems to indicate that the
sigaction(3thr) man page is in error, at least on IRIX 6.5.

Under earlier IRIX releases which did not have a fully POSIX compliant
Pthreads implementation (or cough, Linux, cough), it may indeed be possible
to register per-thread signal handlers. Or heck, libdce.so may be
catching and mungeing all sorts of signals and have its hooks in the
bowels of libpthread (not likely but I haven't thorougly read the
DCE code). However, having carnal knowledge of the subject, I know for
sure this isn't the way that IRIX 6.5 libpthread by itself behaves.

So the short answer is that sigaction(3thr) refers to the DCE library
sigaction routine, so unless you're linking against -ldce you should
get the sigaction(2) behavior. And at that, I don't know that
sigaction(3thr) is correct in the first place.

Hope that helps,
Brent Casavant

--
Brent Casavant bcasavan@sgi.com Forget bright-eyed and
Operating System Engineer http://www.sgi.com/ bushy-tailed; I'm red-
Silicon Graphics, Inc. 44.8562N 93.1355W 860F eyed and bushy-haired.