Re: signal semantics are a pain in the arse

Andi Kleen (ak@muc.de)
27 Nov 1999 10:23:26 +0100

Alan Donovan <adonovan@imerge.co.uk> writes:
>
> Having come back to Linux and having just read W.R.Stevens "Advanced
> Programming in the UNIX Environment" it strikes me that the whole signal
> thing is a right mess. In a signal handler you have no context as to the
> cause of the signal, there's almost nothing you can actually do in the
> handler because of reentrancy problems, and you have to remember to
> restart system calls everywhere (or does Linux do BSD-style
> auto-restarting?).

It does. Just set SA_RESTART in sigaction. glibc even defaults to this
for signal(2), but you should not use that anyways.

Modern signals also support telling you about the context and their cause
and even some payload (via siginfo_t/SA_SIGINFO), unfortunately this so far
only works for queued realtime signals in Linux.

You can e.g. use it by setting a realtime signal (>SIGRTMIN) to a file
descriptor for SIGIO using fcntl(fd,F_SETSIG,sig), and then receive
the fd that caused the SIGIO and even the cause in siginfo->si_band/si_fd.

Even "old" signals can tell you something about their context if you don't
mind CPU specific code via sigcontext_struct.

-Andi

-- 
This is like TV. I don't like TV.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/