mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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;
}

  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®