Mixing threads and signals is usually not recommended, and for sure neither is mixing fork() and threads. See all of perlthrtut, but in particular:

Thinking of mixing fork() and threads? Please lie down and wait until the feeling passes. Be aware that the semantics of fork() vary between platforms. For example, some Unix systems copy all the current threads into the child process, while others only copy the thread that called fork(). You have been warned!

Similarly, mixing signals and threads may be problematic. Implementations are platform-dependent, and even the POSIX semantics may not be what you expect (and Perl doesn't even give you the full POSIX API). For example, there is no way to guarantee that a signal sent to a multi-threaded Perl application will get intercepted by any particular thread. (However, a recently added feature does provide the capability to send signals between threads. See THREAD SIGNALLING in threads for more details.)

I'm not saying it can't ever work, but it's pretty much always a bad idea leading to a fragile implementation, that could have been better implemented by using either signals, or threads, but not both.