All these routines create system-specific portability problems. As noted elsewhere, Perl is at the mercy of your C libraries for much of its system behaviour. It's probably safest to assume broken SysV semantics for signals and to stick with simple TCP and UDP socket operations; e.g., don't try to pass open file descriptors over a local UDP datagram socket if you want your code to stand a chance of being portable.
As mentioned in the signals section, because few vendors provide
C libraries that are safely re-entrant, the prudent
programmer will do little else within a handler beyond setting a numeric
variable that already exists; or, if locked into a slow (restarting) system
call, using die()
to raise an exception and
longjmp(3)
out. In fact, even these may in some cases cause a
core dump. It's probably best to avoid signals except where they are
absolutely inevitable. This will be addressed in a future release of Perl.
Back to NOTES
Forward to AUTHOR
Up to the perlipc manpage