in reply to Re: (tye)Re2: multiple fork()
in thread multiple fork()

Neither operating system nor what you do in the handler is the source of the problem (although they can make the problem worse). And it isn't that I have been having problems (I don't use signal handlers except on rare occasions to attempt clean-up right before death).

The problem is that Perl doesn't protect its internal data structures. A signal can be received while Perl is in the middle of updating some internal data structure and the handler will get called right then. The mear act of calling the handler code uses and updates internal structures so the potential for corruption in these internal structures exists even if your handler does absolutely nothing but return.

        - tye (but my friends call me "Tye")

Replies are listed 'Best First'.
Re: (tye)Re3: multiple fork()
by Rhandom (Curate) on Apr 17, 2001 at 01:15 UTC
    So how do you write a long running daemon in perl that needs to be able to catch terms, ints, and hups. This seems to be a major lacking. (sorry for the eternal node).
[reply]

      Yes, it sucks. I'm a fan of long-running daemons exec()ing themselves from time-to-time even if they weren't written in Perl. And you can usually handle quite a few signals before you get bitten.

      With luck, someone who follows perl5porters more closely than I will chime in and note that certain bits of Perl's code have been protected from signals recently. Otherwise it may be Perl6 before a complete solution appears.

              - tye (but my friends call me "Tye")
[reply]

In Section Seekers of Perl Wisdom