in reply to Interesting behaviour with signals and threads

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.

Replies are listed 'Best First'.
Re^2: Interesting behaviour with signals and threads
by shulam (Novice) on Oct 06, 2019 at 17:17 UTC

    Thanks for the quick answer!

    Yes, this seems a like a perfect example as to why not mix threads, forks and signals.

    I had a previous implementation without the thread which worked okay, so I guess I'm rolling back to that.