Win32 does not 'do signals', they are one unix feature that MS never chose to borrow.

The signal emulation that perl provides on win32 is extremely limited, undocumented from what I have been able to find (and somewhat mysterious!).

Essentially, from my experiments, the only signals a win32 perl program can expect to 'catch' (besides the pseudo-signal __WARN__ and __DIE__) are INT and QUIT.

And then, these will only make it to the perl program if they are initiated by the command line using ^C and ^Break respectively. If you attempt to send these to one perl program from another perl program using kill, they simply never get there.

However, if you attempt to send any other signal from one perl program to another using kill, it will make it there. Unfortunately, it arrives in a form that is completely un-trappable and they all

ABRT|HUP|NUM19|FPE|CLD|NUM12|NUM16|NUM18|NUM17|STOP|NUM24
|NUM10|SEGV|KILL|PIPE|NUM05|CONT|NUM06|NUM07|ILL|ALRM|CHLD
[download]

simply terminate the program! No warnings. No errors! Not a chance in hell of catching them. Your process just dies!

Before anyone say's "Typical MS. Can't get anythng right!". This is not MS' problem. This is how Perl has chosen to emulate signals in Win32. The OS has absolutely no say in any of this.

It would be entirely feasible to implement signals such that they did a vastly better job of emulating the unix way of working within perl programs. Of course they would only work within and between perl programs. However, doing so would require digging deep into the guts of perl's sources, and championing win32 patches to the perl porters. Neither endevour is for the faint of heart.