The pthread_* calls you are making aren't listed as being safe to run
within the context of a signal handler, and could cause a thread
waiting on that condition to be unblocked and start running. Please
see earlier comments about mixing threads and signal handlers.
Okay, fair enough. I'll
Hi--
On May 18, 2009, at 9:23 AM, Peter Steele wrote:
Under what circumstances might a kill -2 nnn not work. I have a
Python app with a signal handler configured to catch INT signals. It
seems to work fine, but we've recently noticed that after the app
has run for a while the kill -2 no
The amount of stuff you're allowed to do safely in a signal handler is
pretty minimal-- you're better off setting a flag, returning from the
signal handler, and having the next run past the main event loop or
whatever check for the flag and handle things in a normal app
context. If you try to
Hi--
On May 18, 2009, at 2:45 PM, Peter Steele wrote:
This is basically what we doing. When the handler is triggered we
set a global variable to indicate the system is shutting down. I
also signal a condition to wake up a sleeping thread. The lack of
log messages indicate that this handler
Subject: Re: Why would a kill -2 not work?
Hi--
On May 18, 2009, at 2:45 PM, Peter Steele wrote:
This is basically what we doing. When the handler is triggered we
set a global variable to indicate the system is shutting down. I
also signal a condition to wake up a sleeping thread. The lack
You're not trying to send a signal within the signal handler itself,
are you? That won't work-- signal delivery is blocked when you're
already running in a signal handler. Also, note that trying to mix
signals with a multithreaded process is complicated
No, I'm not sending a signal within
On May 18, 2009, at 5:32 PM, Peter Steele wrote:
No, I'm not sending a signal within a signal. The signal handler is
this:
pthread_mutex_lock(keep_running_mutex);
KEEP_RUNNING = 0;
pthread_cond_signal(keep_running_cond);
pthread_mutex_unlock(keep_running_mutex);
This works fine, but at some
