From: Axel <Axel.Zeuner@gmx.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, Axel.Zeuner@systor.com
Subject: Re: 2.5.39: Signal delivery to thread groups: Bug or feature
Date: Sun, 29 Sep 2002 18:56:40 +0200 [thread overview]
Message-ID: <20020929163209Z262796-8740+3068@vger.kernel.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0209291023500.12464-100000@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2896 bytes --]
Hello Ingo,
On Sunday 29 September 2002 10:25, you wrote:
> On Sat, 28 Sep 2002, Axel wrote:
> > I played a little bit with the new clone flags and wrote a small test
> > program using two threads: The first (initial) thread blocks all
> > signals. The second thread is created with all signals blocked and
> > inherits the signal mask of the initial thread. It unblocks SIGINT and
> > calls sys_rt_sigtimedwait with the remaining signal mask. Therefore it
> > waits for all signals with exception of SIGINT. In the kernel this
> > yields to an empty signal mask for this thread during the sigwait. No
> > signal handler is installed by the process. Now an external SIGINT is
> > delivered to the whole process: The signal delivery code decides to send
> > this signal directly to the initial thread because no user handler is
> > installed and the signal mask for this thread blocks the signal. The
> > second thread never receives the SIGINT.
>
> could you send me the testcase? Thanks,
unfortunately, my test case is part of a thread library which was intended as
replacement for the old linuxthreads library. The idea of this library is to
have a two level thread library, i.e. posix threads with M:N scheduling on
top of posix threads with 1:1 scheduling. Starting with a 2.4.18+NGPT patches
(futexes+tkill) kernel, I implemented a user level signal forwarding scheme,
for the kernel threads, which worked as expected - slow and with a lot of
system calls.
The test program is attached - in principle a test case from NGPT (change
kth* to pthread*) and use NPT(L) as underlying library.
After having a look at your changes starting with 2.5.35? i decided to drop
further development for the old signal scheme and converted the library to
use all the advantages of the 2.5.X kernels - some of the test cases stopped
working and I had to look for the reasons.
I will test your changes to the kernel as soon as possible
IMHO, they will not work as expected, because in the function
find_unblocked_thread() the real_blocked mask of the thread is also checked:
a thread with all signals blocked calls sys_rt_sigtimedwait to wait for all
signals, all other threads block all signals. If no signal is pending, the
real_blocked mask of this thread is set to all filled and the blocked mask
of this thread is set to empty. Later a signal is sent to the process and the
find_blocked_thread function detects that the sigwait thread has this signal
not set in its blocked mask but set in its real_blocked mask and does not
deliver the signal to this thread as it should.
BTW, what is the reason for the existance of the real_blocked mask? I found a
usage of it only during the sigwaits to store the original signal mask. May
be a local variable would be a cleaner solution.
Axel
Please CC all mails to me, because I read only the archives of the
linux-kernel mailing list.
[-- Attachment #2: Sigwait test program, --]
[-- Type: text/x-c, Size: 2058 bytes --]
#include <kth.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <string.h>
#include <sys/types.h>
void *catch_usr1(void *);
void *catch_usr1(void *p)
{
int signo = SIGUSR1;
int caught;
sigset_t sigs_to_catch;
sigset_t s;
/* Unblock SIGINT */
sigemptyset(&sigs_to_catch);
sigaddset(&sigs_to_catch, SIGINT);
kth_sigmask(SIG_UNBLOCK, &sigs_to_catch, &s);
/* Identify our thread */
printf("catch_usr1: signal %d processing running as thread %lu \n",
signo, kth_self());
printf("catch_usr1: Someone please send pid %d a SIGUSR1\n", getpid());
/*
* We inherited a thread sigmask with all the signals
* blocked. So, we can wait on whatever signals we're
* interested in and (as long as no other thread waits
* for them) we'll be sure return from sigwait() to
* handle it.
*/
/* set this thread's signal mask to block out all other signals */
sigaddset(&sigs_to_catch, signo);
sigwait(&sigs_to_catch, &caught);
printf("catch_usr1: signal %d processing thread caught signal %d\n",
signo, caught);
return (p);
}
extern int main(void)
{
int i;
kth_t threads[1];
int num_threads = 0;
sigset_t sigs_to_block;
/* Identify our thread */
printf("main: running in thread 0x%x\n", (int)kth_self());
/*
* Set this thread's signal mask to block out all other signals
* Other thread's will inherit the mask
*/
/* BLOCK ALL SIGNALS */
sigfillset(&sigs_to_block);
/* sigdelset(&sigs_to_block,SIGINT); */
kth_sigmask(SIG_BLOCK, &sigs_to_block, NULL);
/* Set signal handler for catching SIGSEGV and SIGBUS */
/* Rather than install the action/handler for the process,
we create a thread to wait for the signal */
kth_create(&threads[num_threads++], NULL, catch_usr1, NULL);
printf("main: %d threads created\n", num_threads);
/* wait until all threads have finished */
for (i = 0; i < num_threads; i++) {
kth_join(threads[i], NULL);
printf("main: joined to thread %d \n", i);
}
printf("main: all %d threads have finished. \n", num_threads);
return 0;
}
next prev parent reply other threads:[~2002-09-29 16:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200209281638.g8SGcQi23877@mx1.redhat.com>
2002-09-29 8:25 ` Ingo Molnar
2002-09-29 16:56 ` Axel [this message]
2002-09-29 10:27 ` Ingo Molnar
2002-09-29 10:47 ` Roland McGrath
2002-09-29 12:47 ` [patch] atomic-thread-signals-2.5.39-B5 Ingo Molnar
2002-09-28 17:15 2.5.39: Signal delivery to thread groups: Bug or feature Axel
-- strict thread matches above, loose matches on Subject: below --
2002-09-28 17:14 Axel
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=20020929163209Z262796-8740+3068@vger.kernel.org \
--to=axel.zeuner@gmx.de \
--cc=Axel.Zeuner@systor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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®