in reply to perl threads crashed

Mixing threads and signals is not advisable. Signals are a process-global thing, while threads have little to no notion of signals at all.

I would try to avoid using signals, but as you haven't stated what the real problem you are trying to solve is, I can't give you advice as to what else to use instead.

Replies are listed 'Best First'.
Re^2: perl threads crashed
by liunx (Initiate) on Jun 08, 2011 at 07:10 UTC

    thank you, I just want to write a small daemon program, it suspend until a specific signal wake it up, such as a user defined signal, or the alarm signal, then do some else, after work, suspend again.

      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 }
      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.

        Thanks very much, i have some misunderstand to the signal, thank you for your tips!