signal handler question - SGI

This is a discussion on signal handler question - SGI ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: signal handler question

  1. signal handler question

    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!

  2. Re: signal handler question

    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

  3. Re: signal handler question

    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.

  4. Re: signal handler question

    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 )

  5. Re: signal handler question

    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.

+ Reply to Thread