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 l
>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
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
tions
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 th
>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 wit
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 som
>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
