1. Signals and Windows:

   Not OS supported. Very limited emulation by Perl. Not reliable.

2. Signals and threads:

   Signals are, at best, on platforms that support them natively, a very crude form of IPC.

   They are not a useful mechanism of Inter-Thread Communications.

   From the Linux man pages:

   The signal disposition is a per-process attribute: in a multithreaded application, the disposition of a particular signal is the same for all threads.

   A child created via fork(2) inherits a copy of its parent's signal dispositions. During an execve(2), the dispositions of handled signals are reset to the default; the dispositions of ignored signals are left unchanged.

   A signal may be generated (and thus pending) for a process as a whole (e.g., when sent using kill(2)) or for a specific thread (e.g., certain signals, such as SIGSEGV and SIGFPE, generated as a consequence of executing a specific machine-language instruction are thread directed, as are signals targeted at a specific thread using pthread_kill(3)). A process-directed signal may be delivered to any one of the threads that does not currently have the signal blocked. If more than one of the threads has the signal unblocked, then the kernel chooses an arbitrary thread to which to deliver the signal.

3. Signals and blocking-IO:

   Since 5.8, Perl only delivers signals after the currently executing opcode completes (SAFE_SIGNALS). If the currently executing opcode is a blocking IO operation that may never complete -- eg. reading a line from a pipe -- the signal may never be delivered

4. Sending every known signal:

   Utter desperation. :)

For a solution to your problem that works, see Re^3: trying to get timeout to work (easier with threads).