Signal handling: signal() vs. sigaction()

Signal handling: signal() vs. sigaction()

Post by Arthur H. Gol » Fri, 06 Jul 2001 05:38:33




> I'm writing a multithreaded program where I want only the main thread to
> perform an action when it receives a SIGINT. I set my signal handler in the
> main thread, and used pthread_sigmask(SIG_BLOCK, SIGINT, NULL) in my other
> threads.

> In my main thread, I installed the signal handler function with signal(), but
> I see there is a function called sigaction() as well. The latter seems to be
> more POSIXly-correct than the first, but much harder to use. Is there any
> reason not to use signal()?

Using `sigaction' (which really isn't harder at all) is preferred
becuase it gives you greater flexibility (in terms of what should happen
when another signal is delivered while one is being handled) and
because, unlike signal() its semantics are consistent across platforms
(specifically the fact that SYSV-based systems reset the handler when a
signal is delivered, creating a window that can lead to race conditions,
while BSD-based systems do not).

In your case, however (with the caveat of possibly having to reinstall
the handler), signal should suffice.

HTH,
--ag
--
Artie Gold, Austin, TX  (finger the cs.utexas.edu account for more info)

--
Verbing weirds language.

 
 
 

Signal handling: signal() vs. sigaction()

Post by Andrew Giert » Fri, 06 Jul 2001 06:14:02


 Moshe> I'm writing a multithreaded program where I want only the main
 Moshe> thread to perform an action when it receives a SIGINT. I set
 Moshe> my signal handler in the main thread, and used
 Moshe> pthread_sigmask(SIG_BLOCK, SIGINT, NULL) in my other threads.

I assume you mean pthread_sigmask(SIG_BLOCK, &sigs, NULL) where 'sigs'
has been previously initialised and SIGINT added.

 Moshe> In my main thread, I installed the signal handler function
 Moshe> with signal(), but I see there is a function called
 Moshe> sigaction() as well. The latter seems to be more
 Moshe> POSIXly-correct than the first, but much harder to use. Is
 Moshe> there any reason not to use signal()?

If installing a handler, i.e. anything other than SIG_DFL or SIG_IGN,
always use sigaction(). There are still platforms around that use the
old-style behaviour for signal(), where the disposition is
automatically reset to SIG_DFL before entering the signal handler.

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
                           or <URL: http://www.whitefang.com/unix/>

 
 
 

Signal handling: signal() vs. sigaction()

Post by Nithyanandha » Fri, 06 Jul 2001 13:44:15




>  Moshe> I'm writing a multithreaded program where I want only the main
>  Moshe> thread to perform an action when it receives a SIGINT. I set
>  Moshe> my signal handler in the main thread, and used
>  Moshe> pthread_sigmask(SIG_BLOCK, SIGINT, NULL) in my other threads.

> I assume you mean pthread_sigmask(SIG_BLOCK, &sigs, NULL) where 'sigs'
> has been previously initialised and SIGINT added.

>  Moshe> In my main thread, I installed the signal handler function
>  Moshe> with signal(), but I see there is a function called
>  Moshe> sigaction() as well. The latter seems to be more
>  Moshe> POSIXly-correct than the first, but much harder to use. Is
>  Moshe> there any reason not to use signal()?

> If installing a handler, i.e. anything other than SIG_DFL or SIG_IGN,
> always use sigaction(). There are still platforms around that use the
> old-style behaviour for signal(), where the disposition is
> automatically reset to SIG_DFL before entering the signal handler.

This is true with AIX.

--

Nithyanand.
Siemens, Bangalore, India.
(Opinions expressed are my own and do not reflect the opinions of my employer,
Siemens)

 
 
 

Signal handling: signal() vs. sigaction()

Post by Casper H.S. Dik - Network Security Engine » Fri, 06 Jul 2001 15:28:41


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


>> If installing a handler, i.e. anything other than SIG_DFL or SIG_IGN,
>> always use sigaction(). There are still platforms around that use the
>> old-style behaviour for signal(), where the disposition is
>> automatically reset to SIG_DFL before entering the signal handler.
>This is true with AIX.

And all SVID cmpliant systems (which includes Solaris but probably also
HPUX).

Changing the semantics of signal() was a grave mistake that still causes
porting headaches 20 years later.

It's not like they'd run out of function names.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

Signal handling: signal() vs. sigaction()

Post by phil-news-nos.. » Sun, 08 Jul 2001 15:36:22



|
|>> If installing a handler, i.e. anything other than SIG_DFL or SIG_IGN,
|>> always use sigaction(). There are still platforms around that use the
|>> old-style behaviour for signal(), where the disposition is
|>> automatically reset to SIG_DFL before entering the signal handler.
|
|>This is true with AIX.
|
| And all SVID cmpliant systems (which includes Solaris but probably also
| HPUX).
|
| Changing the semantics of signal() was a grave mistake that still causes
| porting headaches 20 years later.

Anyone know why it was done?  I.e. why it considered useful to make
the handler switch back to SIG_DFL before entering the signal handler?

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |

-----------------------------------------------------------------

 
 
 

Signal handling: signal() vs. sigaction()

Post by Casper H.S. Dik - Network Security Engine » Sun, 08 Jul 2001 17:57:09


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


>| Changing the semantics of signal() was a grave mistake that still causes
>| porting headaches 20 years later.
>Anyone know why it was done?  I.e. why it considered useful to make
>the handler switch back to SIG_DFL before entering the signal handler?

You're mistaken about the direction of the change.  What you dscribe is
the original behaviour.  While we all agree that not switching back to
SIG_DFL and blockign the signal (those are the *two* new things
BSD signal did) are a good idea; what was a bad idea was reusing the
name signal() for the routine.

Casper

--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

1. signal vs. sigaction on S5R3.2 (i.e. ISC 3.0)

Hi programmers.

I have a question about sigaction. My understanding is, that sigaction() (POSIX) will establish a
permanent signal handler in opposite to signal(), which establishes a signal handler, that is
called only once, so that it has to be reestablished on every call to signal. But I found, that
on my system these two system calls behave absolutely the same, thus the system went down because
of to many zombies, where my process was unable to wait() for. Does anybody know s/th abourt this
and may give me a hint ?

Thanks for learning more about the subtle differences.

Regards, Olaf.

--

  Olaf Frommann,                          PHONE: +49 40 7718-2942
  TU Hamburg-Harburg,                     FAX  : +49 40 7718-2573

2. ufs onto CD-ROM?

3. signal vs sigaction

4. Slacking DOS/Windoze?

5. PERFORMANCE HIT MOVING TO SCO5????

6. Alpha vs. Intel: Signal handling

7. sshd

8. signal handler & sigaction()

9. sigaction and signal handler

10. signal() and sigaction() and alarm() help please

11. Sigaction with multiple signals

12. sigaction() signal.h question