Re: Signals, threads and the use of SIGUSR1

From: Loic Domaigne (loic-dev_at_gmx.net)
Date: 10/03/03 

Date: 03 Oct 2003 11:51:59 +0000

Hello Gabriele,

> I am writing an application in C++ on Linux, using threads (this is
> my first experience with pthreads).

<snip>

> I ended up structuring the application with a default behaviour of
> ignoring any SIGINT, SIGHUP, SIGTERM and SIGUSR1 signals both for the
> main process and the 'application threads'. Then I issued a dedicated
> thread waiting for one of these signals whose task is to logically stop
> the other threads and terminate.

 Looks good.

> When I press CTRL-C for instance, the thread catches the signal and
> stops all the other threads. But, when no event is generated, the risk
> is that the thread would be waiting for ever; that's why, when the
> application normally finish without an asynchronous signal, I send a
> 'SIGUSR1' to the thread above and the application normally ends.
>
> I want to know if I am improperly using the SIGUSR1 signal and if -
> in this case - there are other ways of accomplishing this.

Well, I don't know what kind of actions your "signal handler" thread
- the one that is waiting in sigwait() - does exactly, but I guess,
that's OK to just terminate your process as usual, without explicitely
terminate that thread. When the main thread returns, or one of your threads
terminate the process, then your signal handler thread shall be
automatically terminated.

Only when you need some "clean-up" actions (e.g. be sure that the
destructor of some objects is called etc.) in the signal handler thread
upon the normal process ending, then yes, you need to gracefully terminate
that thread.

Using SIGUSR1 is OK with the 'recent' Pthreads lib (I meant younger
than 2 years old). Indeed, older LinuxThreads library used SIGUSR1 and
SIGUSR2 for internal communications, so you weren't able to use that
signal in your application.

As noted by another poster, if you need to do some clean-up in the
signal thread, you could alternatively used pthread_cancel(). Uses
a deferred cancelation only at sigwait() since that function is a
cancellation point. But using SIGUSR1 is also fine.

Regards,
Loic. 

-- 
Article posté via l'accès Usenet http://www.mes-news.com 
Accès par Nnrp ou Web

Relevant Pages

  • Re: Signals, threads and the use of SIGUSR1
    ... > thread waiting for one of these signals whose task is to logically stop ... > the other threads and terminate. ... > 'SIGUSR1' to the thread above and the application normally ends. ...
    (comp.lang.cpp)
  • Re: Design Questions on Termination
    ... but SIGUSR1 is designed for applications ... POSIX requires that the standard POSIX signals be available to applications. ... but what about OpenVMS or the Win32 "pthread" library, which don't have real UNIX signals at all? ...
    (comp.programming.threads)
  • Re: Signals, threads and the use of SIGUSR1
    ... > thread waiting for one of these signals whose task is to logically stop ... > 'SIGUSR1' to the thread above and the application normally ends. ... terminate all your threads before the application terminates. ...
    (comp.lang.cpp)
  • Re: Signals, threads and the use of SIGUSR1
    ... > thread waiting for one of these signals whose task is to logically stop ... > 'SIGUSR1' to the thread above and the application normally ends. ... terminate all your threads before the application terminates. ...
    (comp.unix.programmer)
  • Re: help with sigaction
    ... > a SIGUSR1 to the father when it has finished. ... Signals are never going to be a reliable solution to this. ... If the parent doesn't really care when the child is done, ... In order to understand recursion you must first understand recursion. ...
    (comp.unix.programmer)