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
[Site Home] [Netdev] [Ethernet Bridging] [Linux Wireless] [Kernel Newbies] [Memory] [Security] [Linux for Hams] [Netfilter] [Bugtraq] [Rubini] [Photo] [Yosemite] [Yosemite News] [MIPS Linux] [ARM Linux] [Linux RAID] [Linux Admin] [Samba] [Video 4 Linux] [Linux Resources]