I have found another problem, but your solution can improve situation I think.
When I have removed printf after pthread_kill program works. I thinks
scenario is:
1. Signal arrives when printf still works
2. Printf (or system) has locked some structeres associated with stream
3. Then thread1 is suspended so printf will never return and never
unlock theese structures
4. In main thread printf blocks on stdout stream.
To check my concept I have used fprintf to stderr and it does't blocks
main thread. Only prints to stdout does.
What are you thinking about this concept?
W dniu 22 lipca 2009 22:31 użytkownik Gedare Bloom
<gedare@xxxxxxxxxxxxxx> napisał:
> The problem is that the thread looping in the signal handler has equal
> priority to the 'main' thread, so that it is exhausting all of the
> compute resources and the main thread is never scheduled.
>
> You can correct this by giving your newly created thread a lower
> priority (see below). Good luck!
>
> -G
>
> --- orig.c 2009-07-22 16:28:44.000000000 -0400
> +++ test.c 2009-07-22 16:28:02.000000000 -0400
> @@ -1,5 +1,6 @@
> #include <signal.h>
> #include <stdio.h>
> +#include <sched.h>
>
> void suspend(int sig) {
> printf("suspending\n");
> @@ -28,6 +29,8 @@
>
> struct sigaction sa;
> pthread_t thread1;
> + struct sched_param sp;
> + int policy;
>
> sa.sa_handler = suspend;
> sa.sa_flags = SA_RESTART;
> @@ -35,6 +38,9 @@
> sigaction(SIGUSR1, &sa, NULL);
>
> pthread_create(&thread1, 0, loop_func, 0);
> + pthread_getschedparam(thread1, &policy, &sp);
> + sp.sched_priority = sched_get_priority_min(policy);
> + pthread_setschedparam(thread1, policy, &sp);
> wait_some_time();
>
> pthread_kill(thread1, SIGUSR1);
> @@ -43,4 +49,3 @@
>
> return 0;
> }
> -
>
>
> 2009/7/22 Mirski Paweł <mirskip87@xxxxxxxxx>:
>> Hi all,
>> I have problem with handling signals in simple program. Program starts
>> one thread (only task of this thread is printing "Hello World") and
>> after while sends signal to this thread (signal handler is previously
>> registered). In signal handler is infinite loop that should suspend
>> thread forever. But it suspends whole application. I think this
>> problem is related with printf function because when I replace it with
>> with linux write sys function problem does not occures. And one more
>> info: problem occures not always, but most of time; maybe somewhere
>> there is a race condition.
>> This is whole code of application:
>>
>> #include <signal.h>
>> #include <stdio.h>
>>
>> void suspend(int sig) {
>> printf("suspending\n");
>> fflush(stdout);
>> while(1);
>> }
>>
>>
>> void* loop_func(void* arg) {
>> int i = 0;
>> while(1) {
>> if(i % 10000 == 0) {
>> printf("Hello World %d\n", i);
>> fflush(stdout);
>> }
>> i++;
>> }
>> }
>>
>> void wait_some_time() {
>> int i;
>> for(i = 0; i < 10000000; i++) { }
>> }
>>
>> int main(void) {
>>
>> struct sigaction sa;
>> pthread_t thread1;
>>
>> sa.sa_handler = suspend;
>> sa.sa_flags = SA_RESTART;
>> sigemptyset(&sa.sa_mask);
>> sigaction(SIGUSR1, &sa, NULL);
>>
>> pthread_create(&thread1, 0, loop_func, 0);
>> wait_some_time();
>>
>> pthread_kill(thread1, SIGUSR1);
>> printf("Waiting for terminate...\n");
>> wait_some_time();
>>
>> return 0;
>> }
>>
>> Could any body tell me why this signal handler hangs whole
>> application? It should hangs only one thread. It seems to be be a bug
>> in linux kernel or maybe in C library. How can I solve this problem?
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
