Hi,
      
     i have a problem with sigwait() in a multithreaded program. 

     In this program some thread will be generating the signal SIGUSR1 at 
     some time(asynchronously) and there is a dedicated thread for handling 
     the asynchronous(SIGUSR1 in my case) signals.
 
     The sinal handling thread uses sigwait() to catch the signal, however 
     the signal is not caught by the sigwait() function. I have blocked the 
     signal SIGUSR1 before the threads are created aswell before the sigwait() 
     is called.

     I have included a variant of the program. 

     Any help will be highly appreciated.

     Thanks and regards,

     Neelakantan
    
***************************************************************** 
     OS : Redhat 9 kernel version 2.4.20

     Compiler: g++ (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5).

     Note: if i send the signal SIGUSR1 from the command prompt, 
           the signal has been caught.

****************   sinal.cpp ************************************
#include<iostream>
#include<pthread.h>
#include<signal.h>
#include<errno.h>
#include<unistd.h>
using namespace std;
void* fun(void* arg)
{
        int i = 0;
        while(i<10)
        {
          sleep(2);
          kill(getpid(),SIGUSR1);
          cout << "SIGUSR1 Has been sent" << i++ << endl;
        }
        return NULL;
}
int main()
{
        pthread_t tid;
        sigset_t set;
        sigemptyset(&set);
        sigaddset(&set, SIGUSR1);
        sigaddset(&set, SIGINT);
        pthread_sigmask(SIG_BLOCK, &set, NULL);
        int status = pthread_create(&tid,0,fun,0);
        if (status != 0)
        {
          cout << "Thread Creation Failed" << endl;
          exit(0);
        }
        int signal = 0;
        while(true)
        {
          sigwait(&set,&signal);
          if (signal == SIGUSR1)
           {
                cout << "SIGUSR1 signal recieved" << endl;
                break;
           }
          if(signal == SIGINT)
           {
                cout << "SIGINT signal recieved" << endl;
                break;
           }
        }
        cout << "Main is exiting" << endl;
        exit(0);
}
******************* signal.cpp ends ***************************

Neelakantan wrote:
> Hi,
>       
>      i have a problem with sigwait() in a multithreaded program. 
> 
>      In this program some thread will be generating the signal SIGUSR1 at 
>      some time(asynchronously) and there is a dedicated thread for handling 
>      the asynchronous(SIGUSR1 in my case) signals.
>  
>      The sinal handling thread uses sigwait() to catch the signal, however 
>      the signal is not caught by the sigwait() function. I have blocked the 
>      signal SIGUSR1 before the threads are created aswell before the sigwait() 
>      is called.
You have no way to determin wether a given thread catches/receives the
signal. Probably some other thread received it.

Neelakantan wrote:
> Hi,
>
>      i have a problem with sigwait() in a multithreaded program.
>
>      In this program some thread will be generating the signal
SIGUSR1 at
>      some time(asynchronously) and there is a dedicated thread for
handling
>      the asynchronous(SIGUSR1 in my case) signals.
>
>      The sinal handling thread uses sigwait() to catch the signal,
however
>      the signal is not caught by the sigwait() function. I have
blocked the
>      signal SIGUSR1 before the threads are created aswell before the
sigwait()  is called.
>

       If its not caught then your registered signal handler isnt
registered
       properly with the OS. !

       You need to override the default signal handling by OS with your
       signal handlers at the right place :-)
       May be reading your OS documentation on signal handlers might be
of
       some clue/help of howto accomplish it.

- Roopa

>      I have included a variant of the program.
>
>      Any help will be highly appreciated.
>
>      Thanks and regards,
>
>      Neelakantan
>



> *****************************************************************
>      OS : Redhat 9 kernel version 2.4.20
>
>      Compiler: g++ (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5).
>
>      Note: if i send the signal SIGUSR1 from the command prompt,
>            the signal has been caught.
>
> ****************   sinal.cpp ************************************
> #include<iostream>
> #include<pthread.h>
> #include<signal.h>
> #include<errno.h>
> #include<unistd.h>
> using namespace std;
> void* fun(void* arg)
> {
>         int i = 0;
>         while(i<10)
>         {
>           sleep(2);
>           kill(getpid(),SIGUSR1);
>           cout << "SIGUSR1 Has been sent" << i++ << endl;
>         }
>         return NULL;
> }
> int main()
> {
>         pthread_t tid;
>         sigset_t set;
>         sigemptyset(&set);
>         sigaddset(&set, SIGUSR1);
>         sigaddset(&set, SIGINT);
>         pthread_sigmask(SIG_BLOCK, &set, NULL);
>         int status = pthread_create(&tid,0,fun,0);
>         if (status != 0)
>         {
>           cout << "Thread Creation Failed" << endl;
>           exit(0);
>         }
>         int signal = 0;
>         while(true)
>         {
>           sigwait(&set,&signal);
>           if (signal == SIGUSR1)
>            {
>                 cout << "SIGUSR1 signal recieved" << endl;
>                 break;
>            }
>           if(signal == SIGINT)
>            {
>                 cout << "SIGINT signal recieved" << endl;
>                 break;
>            }
>         }
>         cout << "Main is exiting" << endl;
>         exit(0);
> }
> ******************* signal.cpp ends ***************************

Neelakantan wrote:
>       
>      i have a problem with sigwait() in a multithreaded program. 
> 
>      In this program some thread will be generating the signal SIGUSR1 at 
>      some time(asynchronously) and there is a dedicated thread for handling 
>      the asynchronous(SIGUSR1 in my case) signals.
>  
>      The sinal handling thread uses sigwait() to catch the signal, however 
>      the signal is not caught by the sigwait() function. I have blocked the 
>      signal SIGUSR1 before the threads are created aswell before the sigwait() 
>      is called.

Your program looks OK... Although you should be checking the return 
status of sigwait(). Right now, if it were to fail, you'd go into an 
infinite hot loop.

I wonder if you could be running LinuxThreads? That might explain why it 
works when you use the kill(1) but not when the program uses kill(2). 
LinuxThreads was able to manage only a loose approximation of the POSIX 
process model; and one of the weakest areas was signal handling. In 
particular, there was no such thing as a "process pending signal mask"; 
a blocked signal would "stick" to the thread it hit first. When you 
kill(1) the "process", externally, it may hit the main thread (which is 
blocked in sigwait() and takes the signal as you expect), while the 
kill(2) from within a different thread delivers the signal to itself, 
finds it blocked, and pends against that thread... never reaching the 
main thread's sigwait(). NGPT, however, shouldn't have this problem, and 
I thought that was the default on Red Hat 9...

-- 
Dave Butenhof, David.Butenhof@hp.com
HP Utility Pricing software, POSIX thread consultant
Manageability Solutions Lab (MSL), Hewlett-Packard Company
110 Spit Brook Road, ZK2/3-Q18, Nashua, NH 03062

> Your program looks OK... Although you should be checking the return 
> status of sigwait(). Right now, if it were to fail, you'd go into an 
> infinite hot loop.
> 
> I wonder if you could be running LinuxThreads? That might explain why it 
> works when you use the kill(1) but not when the program uses kill(2). 
> LinuxThreads was able to manage only a loose approximation of the POSIX 
> process model; and one of the weakest areas was signal handling. In 
> particular, there was no such thing as a "process pending signal mask"; 
> a blocked signal would "stick" to the thread it hit first. When you 
> kill(1) the "process", externally, it may hit the main thread (which is 
> blocked in sigwait() and takes the signal as you expect), while the 
> kill(2) from within a different thread delivers the signal to itself, 
> finds it blocked, and pends against that thread... never reaching the 
> main thread's sigwait(). NGPT, however, shouldn't have this problem, and 
> I thought that was the default on Red Hat 9...

Hi,
   If linuxThreads behaves so, Is it not violating the semantics that
is mentioned in the man page of sigwait()?. I despiratly need a way
out from this problem?
Any suggestions will be highly appreciated.

Thanks and regards,
Neelakantan.

On 12 Mar 2005 07:24:08 -0800, Neelakantan <neelakantan@cins.unipune.ernet.in> wrote:

> Hi,
>    If linuxThreads behaves so, Is it not violating the semantics that
> is mentioned in the man page of sigwait()?. I despiratly need a way
> out from this problem?
> Any suggestions will be highly appreciated.
>
Try learning how to use pthread_cond_(signal|broadcast|wait|timedwait).
You shouldn't use unix signals unless you literally want to do something
in the worst way.  And if you want to do something in the worst way
possible, don't expect anyone else to waste time trying to help you.

-- 
Joe Seigh

On Sat, 12 Mar 2005 10:37:14 -0500,
    Joe Seigh <jseigh_01@xemaps.com> wrote:


> On 12 Mar 2005 07:24:08 -0800, Neelakantan <neelakantan@cins.unipune.ernet.in> wrote:
>
>> Hi,
>>    If linuxThreads behaves so, Is it not violating the semantics that
>> is mentioned in the man page of sigwait()?. I despiratly need a way
>> out from this problem?
>> Any suggestions will be highly appreciated.
>>
> Try learning how to use pthread_cond_(signal|broadcast|wait|timedwait).
> You shouldn't use unix signals unless you literally want to do something
> in the worst way.  And if you want to do something in the worst way
> possible, don't expect anyone else to waste time trying to help you.
>


It was mentiond this was RedHat version 9, and this version introduced
the NPTL version of pthreads, which claims to be more conforming to
the standard than the old linux threads were.  For old linux kernels
the pthreads had to use SIGUSR for its internal purpose as no other signals
were available.  With current kernels this should not be required.


Villy

Villy Kruse <vek@station02.ohout.pharmapartners.nl> writes:

> It was mentiond this was RedHat version 9, and this version introduced
> the NPTL version of pthreads, which claims to be more conforming to
> the standard than the old linux threads were.  For old linux kernels
> the pthreads had to use SIGUSR for its internal purpose as no other signals
> were available.  With current kernels this should not be required.

AFAIK SIGUSR{1,2} became available earlier than NPTL, in Linux 2.4
(NPTL requires Linux 2.6).

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

On Mon, 14 Mar 2005 11:29:58 +0100,
    Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> wrote:


>
> AFAIK SIGUSR{1,2} became available earlier than NPTL, in Linux 2.4
> (NPTL requires Linux 2.6).
>

RedHat backported NPTL to the 2.4 kernel for the RH9 and AS3 versions.

Villy