Re^3: perl threads crashed

I don't see any need for threads. Just do your work within the sig handler. I believe that Perl sets up sigaction mask to block all signals while inside of a handler, so there is no extra stuff required to prevent a re-entrant call into the handler. The below code calls handler every 5 seconds. If you do a kill -s USR1 pid, that causes an extra call to handler. The sleep 100 never actually completes because Perl implements sleep in terms of ALRM and when the alarm goes off, it cancels the sleep. I would definitely not use INT as one of your signals. I mean "read database and send to socket" is not an action one would normally think of for CTL-C! USR1 is a lot better and intended for this sort of thing.

#!/usr/bin/perl -w
use strict;

$SIG{USR1} = \&handler;
$SIG{ALRM} = \&handler;

while (1){alarm 5; sleep 100;}

sub handler
{
   print "Do work \n"; #your get_message,send_message calls
}
[download]

Update: If SIGPIPE happens in send_message(), it won't be handled until after handler finishes. I don't see a big deal with that as since you don't have a handler installed for SIGPIPE, you are going to die anyway. I would consider connecting to the DB before the while(1)..leave connection open if you are going to use it every 10 seconds, ditto for the other socket.

Comment on Re^3: perl threads crashed Download Code

Replies are listed 'Best First'.
Re^4: perl threads crashed by liunx (Initiate) on Jun 09, 2011 at 01:21 UTC
Thanks very much, i have some misunderstand to the signal, thank you for your tips!	[reply]
Re^5: perl threads crashed by Marshall (Canon) on Jun 09, 2011 at 02:13 UTC
Yes, from looking at your code, I think there are some misunderstandings about sigaction and sigprocess masks. The sigaction structure contains the rules about how a signal is delivered. You can cause it to be ignored, have the default action taken, or have some code that you supply be run. In addition to that you can specifiy a set of signals to block/unblock while your signal handler is running. This is not the same as you setting a sigproc mask at the start of the handler. The sigaction mask will be in effect before even the first instruction in the handler is executed. When the handler finishes the signal blocking mask goes back to whatever it was before the signal. The C code for a normal setup would look like below. I am more familiar with the C, but there are Perl equivalents if you need to deal with this low of a level. `sigset_t newmask; struct sigaction sa; sa.sa_handler= handler; //handler is name of subroutine sigfillset(&sa.sa_mask); //set up to block all signals sigdelset(&sa.sa_mask, SIGPIPE); // allow SIGPIPE to interrupt handler // normally not done // allowing this is non-typical sa.sa_flags =0; sigaction(SIGUSR1, &sa, NULL);` [download] Sigproc mask is a whole different thing. It is seldom necessary to mess with this. An example usage might be to temporarily block CTL-C, CTL-\ while updating some critical file. Block some signals, do something, unblock signals. This is different than sigaction mask which is the temporary blocking mask that is only in effect for the duration of the signal handler code. Signals are not queued - the state is a yes/no situation. If a signal is blocked and it happens say 5 times. The result of this is that the state is called "pending". This is a signal that has occurred, but has not yet been delivered. When unblocked, the signal will just be delivered once, not 5 times.	[reply] [d/l]