|
Home > Archive > Unix Programming > August 2005 > POSIX signal handling versus traditional signal handling
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
POSIX signal handling versus traditional signal handling
|
|
| usenet@sta.samsung.com 2005-08-23, 9:02 pm |
| I am trying to compare POSIX signal handling with traditional signal
handling. I do see some similarities (posted some sample code to
comp.sources.d), but I see some differences as well. When I say
differences, I mean differences beyond the obvious differences needed
for handling real-time behavior.
For example, in all the code snippets of POSIX Real-time signal
handling that I have seen, I don't see any checks to see if the
signal has been previously set to SIG_IGN, and keeping it that way in
case it has. Also, I don't see the signal handler resetting the
signal, to prevent it from being reset to its default value. Is it
just the code snippets that I am seeing, or are they indeed different?
Thanks,
Gus
| |
| Ulrich Hobelmann 2005-08-24, 2:49 am |
| usenet@sta.samsung.com wrote:
> I am trying to compare POSIX signal handling with traditional signal
> handling. I do see some similarities (posted some sample code to
> comp.sources.d), but I see some differences as well. When I say
> differences, I mean differences beyond the obvious differences needed
> for handling real-time behavior.
>
> For example, in all the code snippets of POSIX Real-time signal
> handling that I have seen, I don't see any checks to see if the
> signal has been previously set to SIG_IGN, and keeping it that way in
> case it has. Also, I don't see the signal handler resetting the
> signal, to prevent it from being reset to its default value. Is it
> just the code snippets that I am seeing, or are they indeed different?
AFAIK, BSD and POSIX signals (i.e. everything except ooold Unix V7 or
something) are reliable, so even if you process receives two same
signals in a short timeframe, the behavior will probably be that after
the first handler returns, the second signal is delivered. Old behavior
simply crashed the program, because the signal handler didn't have time
to re-set the handler. I don't know about real-time stuff, though.
--
I believe in Karma. That means I can do bad things to people
all day long and I assume they deserve it.
Dogbert
| |
| Maxim Yegorushkin 2005-08-24, 7:52 am |
|
usenet@sta.samsung.com wrote:
> For example, in all the code snippets of POSIX Real-time signal
> handling that I have seen, I don't see any checks to see if the
> signal has been previously set to SIG_IGN, and keeping it that way in
> case it has.
???
> Also, I don't see the signal handler resetting the
> signal, to prevent it from being reset to its default value. Is it
> just the code snippets that I am seeing, or are they indeed different?
Under POSIX you can specify if a handler should be reset or left
unchanged using flags using sigaction().
http://www.opengroup.org/onlinepubs.../sigaction.html
| |
| Nils Weller 2005-08-24, 6:11 pm |
| On 2005-08-24, Ulrich Hobelmann <u.hobelmann@web.de> wrote:
> usenet@sta.samsung.com wrote:
> AFAIK, BSD and POSIX signals (i.e. everything except ooold Unix V7 or
> something) are reliable, so even if you process receives two same
Note that in System V, signal() was never fixed, so you still have to
use sigset() (introduced in SVR3), sigaction() or bsd_signal() instead
to get reliable signals - or link with the BSD compatibility library to
make signal() behave like bsd_signal(). The problem is that POSIX leaves
the choice of reset-or-don't-reset after calling signal() up to the
implementation, so System V derivatives continue to do it the way
they've always done it: Don't reset.
> signals in a short timeframe, the behavior will probably be that after
> the first handler returns, the second signal is delivered. Old behavior
No, the second signal will be lost. sigqueue() can send signals with
the semantics you've described, however. Unfortunately, queued signals
are a realtime extension still not provided by FreeBSD/NetBSD/OpenBSD/
MacOS X (and I seem to recall that older Linux implementations do not
support queueing of non-realtime (SIGRTMIN - SIGRTMAX) signals.)
--
Nils R. Weller, Bremen / Germany
My real email address is ``nils<at>gnulinux<dot>nl''
.... but I'm not speaking for the Software Libre Foundation!
| |
| Villy Kruse 2005-08-25, 2:54 am |
| On 24 Aug 2005 16:27:51 GMT,
Nils Weller <me@privacy.net> wrote:
> On 2005-08-24, Ulrich Hobelmann <u.hobelmann@web.de> wrote:
>
> Note that in System V, signal() was never fixed, so you still have to
> use sigset() (introduced in SVR3), sigaction() or bsd_signal() instead
> to get reliable signals
SysV sigset() differs from BSD signal() in whether or not restartable
syscalls are actualy restarted when the signal handler terminates.
Villy
|
|
|
|
|