Re: [PATCH] Reset the terminal state if we are killed by a fatal signal.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 8, 2008 at 12:38 AM, Karel Zak <kzak@xxxxxxxxxx> wrote:
> On Sun, Apr 06, 2008 at 12:15:46PM +0100, James Youngman wrote:
>  > -static struct termios termios;
>  > -static int termios_set = 0;
>  > +static volatile struct termios termios;
>
>   Do we really need "volatile" here?

The code may never be run on a system where it actually makes a
difference.   So I guess we can do without it - and especially so
since it causes compilation errors.


>  > +static void
>  > +fatalsig(int sig) {
>  > +     /* We received a fatal signal.  Reset the terminal.
>  > +      * Also reset the signal handler and re-send the signal,
>  > +      * so that the parent process knows which signal actually
>  > +      * caused our death.
>  > +      */
>  > +     signal(sig, SIG_DFL);
>
>   You needn't to reset the handler to SIG_DFL. That's default behaviour
>   when you define the handler by signal(2).

It's not something you can portably rely on; better safe than sorry.
>From the signal(2) manpage on my system:

   Portability
       The original Unix signal() would reset the handler to SIG_DFL, and Sys‐
       tem V (and the Linux kernel and libc4,5) does the same.  On  the  other
       hand,  BSD does not reset the handler, but blocks new instances of this
       signal from occurring during a call of the handler.  The glibc2 library
       follows the BSD behavior.


James.
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux