What os/systems have you had trouble on. I got my example from perlipc. There is a note in there which says:
"But that will be problematic for the more complicated handlers that need to reinstall
themselves. Because Perl's signal mechanism is currently based on the signal(3) function from
the C library, you may sometimes be so misfortunate as to run on systems where that function is
"broken", that is, it behaves in the old unreliable SysV way rather than the newer, more
reasonable BSD and POSIX fashion. So you'll see defensive people writing signal handlers like
this:"
and then an example similar to mine follows. I have found it to be very stable under a 2.2.16 linux kernel. Maybe other os's have gaping holes in them, but the linux distros I have tried it on are fine.
| [reply]
[d/l] |
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")
| [reply] |
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] |
