A big ol' for loop is no substitute for a nice little sleep statement.

-sauoq
"My two cents aren't worth a dime.";

well, as far as forking is concerned, if i remember by Unix systems course, each process gets a slice of the processor, so even though one is stuck in the for (;;) loop, the other process should still execute. So in that sense, here, a sleep = for ();

if i remember by Unix systems course, each process gets a slice of the processor, so even though one is stuck in the for (;;) loop, the other process should still execute.

A slice, in that sense, is a "time slice." Each process gets the cpu for a slice of time not for a single instruction or something. (Otherwise, there'd be a lot of overhead to no good purpose.)

So in that sense, here, a sleep = for ();

Not unless you can guarantee that the empty for loop won't complete before the child is able to complete setting its signal handler. The empty for loop is very quick. The sleep, on the other hand, actually blocks for a period of time. So, in no sense at all does a sleep equal a for loop.

-sauoq
"My two cents aren't worth a dime.";

I'm guessing your perl or your os may not like signals...
--
Mike

its ActivePerl 5.6.1 build 633 (multi-thread) running under Windows NT (perl is actually called from within the cygwin environment, however, execution of program from outside of cygwin still has the same effect)

Right; ActivePerl doesn't _really_ fork when you use fork, so that example's not going to work for you. I'm pretty sure the pseudo-forked processes they use wouldn't handle signals, even if they were supported under NT, which they aren't :)

This is from the ActivePerl docs, under "Windows Quirks".

Why doesn't signal handling work on Windows?

Signals are unsupported by the Win32 API. The C 
Runtime provides crude support for signals, but there 
are serious caveats, such as inability to die() or exit() 
from a signal handler. Perl itself does not guarantee that 
signal handlers will not interrupt critical operations such 
as memory allocation, which means signal invocation may 
throw perl internals into disarray. For these reasons, 
signals are unsupported at this time.
[download]

Try this script on a Linux box, or, if you're VERY brave, with a native cygwin perl. But be warned, with 5.6.1 under Cygwin, playing with that kind of script causes bad things to happen for me.
--
Mike