Re: Why would a kill -2 not work?

2009-05-19 Thread Peter Steele
>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 rework our signal handler logic to avoid using any 
calls that are not considered signal-safe. Better to be "safe" than sorry... 
:-) 

Thanks for the feedback. 

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"


Re: Why would a kill -2 not work?

2009-05-18 Thread Chuck Swiger

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 point it seems to stop working. The app  
just continues to run as if it never received the -2 signal. We have  
to use a kill -9 to kill it, which we want to avoid because this  
prevents our shutdown code from executing.


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.


--
-Chuck

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"


Re: Why would a kill -2 not work?

2009-05-18 Thread Peter Steele
>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 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 point it seems to stop working. The app just 
continues to run as if it never received the -2 signal. We have to use a kill 
-9 to kill it, which we want to avoid because this prevents our shutdown code 
from executing. 

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"


RE: Why would a kill -2 not work?

2009-05-18 Thread Gary Gatten
What he said.  It's better to just stick with -9; it almost always
works!

;-)

-Original Message-
From: owner-freebsd-questi...@freebsd.org
[mailto:owner-freebsd-questi...@freebsd.org] On Behalf Of Chuck Swiger
Sent: Monday, May 18, 2009 4:49 PM
To: Peter Steele
Cc: #freebsd-questions
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 of  
> log messages indicate that this handler never gets called and the  
> system carries on as if the kill -2 never happened.

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

-- 
-Chuck

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
"freebsd-questions-unsubscr...@freebsd.org"








"This email is intended to be reviewed by only the intended recipient
 and may contain information that is privileged and/or confidential.
 If you are not the intended recipient, you are hereby notified that
 any review, use, dissemination, disclosure or copying of this email
 and its attachments, if any, is strictly prohibited.  If you have
 received this email in error, please immediately notify the sender by
 return email and delete this email from your system."


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"


Re: Why would a kill -2 not work?

2009-05-18 Thread Chuck Swiger

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 never gets called and the  
system carries on as if the kill -2 never happened.


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


--
-Chuck

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"


Re: Why would a kill -2 not work?

2009-05-18 Thread Peter Steele
>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 do anything involving malloc() or s/printf, 
>etc, you're running risks. "man sigaction" is likely to be 
>informative 

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 
never gets called and the system carries on as if the kill -2 never happened. 


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"


Re: Why would a kill -2 not work?

2009-05-18 Thread Chuck Swiger

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 longer works. This seems pretty  
suspicious, perhaps indicating our app is misbehaving in some way.  
What might cause the signal handler to stop working?


The main reason might be that your process is already in another  
signal handler or is otherwise blocked in a system call and won't get  
the new signal until it completes the current situation.


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 do anything involving malloc() or s/printf,  
etc, you're running risks.  "man sigaction" is likely to be  
informative


Regards,
--
-Chuck

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"