From: Tobias Grundmann <lk@tobias-grundmann.de>
To: linux-kernel@vger.kernel.org
Subject: Question about ignoring blocked signals
Date: Sun, 27 Feb 2005 09:21:48 +0100 [thread overview]
Message-ID: <4221831C.6000509@tobias-grundmann.de> (raw)
Hi,
I have a question regarding blocked signals:
Is the current implementation to ignore attempts to set SIG_IGN on
blocked signals correct?
The following code will go into an endless loop on kernels 2.6.10 and
2.4.25, which is IMHO not the behaviour one would expect.
--------------------
#include <signal.h>
#include <sys/types.h>
#include <unistd.h>
volatile int sig_received = 0;
void sigio_handler_ex (int signum, siginfo_t * siginfo, void * ucontext)
{
struct sigaction sigio_action;
sig_received++;
printf("handler %d\n",sig_received);
sigio_action.sa_handler = SIG_IGN;
sigio_action.sa_flags = 0;
sigemptyset(&sigio_action.sa_mask);
sigaction (SIGIO, &sigio_action, 0);
kill(getpid(),SIGIO);
sigio_action.sa_sigaction = sigio_handler_ex;
sigio_action.sa_flags = SA_SIGINFO;
sigemptyset(&sigio_action.sa_mask);
sigaction (SIGIO, &sigio_action, 0);
}
int main(int argc, char **argv) {
struct sigaction sigio_action;
sigio_action.sa_sigaction = sigio_handler_ex;
sigio_action.sa_flags = SA_SIGINFO;
sigemptyset(&sigio_action.sa_mask);
sigaction (SIGIO, &sigio_action, 0);
kill(getpid(),SIGIO);
while (! sig_received) {
printf("waiting for signal\n");
sleep(1);
}
kill(getpid(),SIGIO);
printf("%d signals handled\n",sig_received);
}
--------------------
In kernel 2.6.10/kernel/signal.c sig_ignored() I found this comment:
...
/*
* Blocked signals are never ignored, since the
* signal handler may change by the time it is
* unblocked.
*/
if (sigismember(&t->blocked, sig))
return 0;
...
so it seems this behaviour is intentional, but I don't understand
it. Why should it matter if a signal handler may change while blocked,
if it is ignored also, which is a user request?
The machine im writing this mail on runs with the above lines
commented out without any problems so far...
All this resulted from problems a customer had with implementing a
whole protocol-stack to a serially attached device in a
signal-handler. After the handler ran (with SIG_IGN) there was always
an extra SIGIO which triggered the handler again. Of course the real
fix was to move the protocol-stack out of the handler but still it
should have worked since it was a controlled environment (so there
wasn't even a race between entering the handler and setting
SIG_IGN). Oh and it worked for years under some realtime variant of
hp-unix.
Please be so kind to CC any answer to me directly since I'm
currently not subscribed to lkml.
Yours
Tobias Grundmann
reply other threads:[~2005-02-27 8:22 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4221831C.6000509@tobias-grundmann.de \
--to=lk@tobias-grundmann.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®