[omniORB] RE: Catching SIGTERM/SIGHUP using omniORB v3.0

[Mark Johnson]

Well can anyone give a "best practices" or some common (complete?) example
of how to do this? I mean how many ways can you alert your application that
a SIGTERM has just been recieved?

This is what I'm doing (which is wrong).

void HandleSIGTERM(int sig)
{
  signal( sig, HandleSIGTERM );  // should change this to 'sigaction'
  ThreadInfo::setStopping();
  SLEEP( 5 ); // KLUDGE!
  exit( 0 );  // FIX THIS: don't know how/where to stop CORBA::run() yet...
}

and all my threads have this as a main loop:

void MyCorbaThread::run( void * arg )
{
   while( ThreadInfo::isStopping() == false )
   {
      // ... do stuff...
   }
}

So in the archives I have found the following, which is pretty informative:
http://www.uk.research.att.com/omniORB/archives/2001-01/0190.html

Would anyone else be interested in having an example of how to handle
signals as a part of the OminORB distribution.  I could maybe contribute,
but I'm not sure that I am qualified. Right now, I'm very much a newbie.

> -----Original Message-----
> From: Huw Rogers [mailto:count0@building2.co.jp]
> Sent: Tuesday, September 18, 2001 4:12 AM
> To: Mark Johnson
> Cc: 'OmniOrb Mailing List (E-mail)'
> Subject: Re: [omniORB] RE: Catching SIGTERM/SIGHUP using omniORB v3.0
> 
> 
> Mixing signal handling, threads and ORBs
> is hazardous. In particular, a signal handler
> cannot safely acquire a mutex or create
> another thread. You can cause core dumps and
> deadlocks if you try, particularly on SMP systems.
> This means you can't call any ORB library
> functions either directly or indirectly from
> within signal handlers.
> 
> In fact, the only portable and safe thing to do
> is have a separate cleanup thread waiting on
> a semaphore and call sem_post() in the signal
> handler, which is one of the very few pthreads
> functions that is portably Async-signal safe
> (pthread_cond_broadcast and/or pthread_cond_signal
> are not).
> 
> Also, use sigaction() to register handlers, to
> avoid the usual ambiguities of signal().
> 
> Mixing Unix signal handlers and shutdown of
> multithreaded libraries is an FAQ - it should be
> definitively described somewhere, but isn't
> AFAIK.
> 
> 	-Huw
> 
>