Please keep in mind the the signal handler itself is shared by all threads which means each process has it's signal handlers defined.

Hm. Does that mean that you are mixing threads and processes? Or are you just conflating the two terms? I'm going to assume the latter.

In a threaded process, if you install a signal handler using the 'normal mechanism' of %SIG, then that signal handler will only be called on the main thread. I assume--but haven't tested--this is the same for sigtrap.

I did try detaching the thread. But the error message kept coming.

It will unless you upgrade to a later version of perl. The warning about detached threads is no longer produced for 5.8.9. It may have been removed earlier, I don't recall, but if you were to upgrade, you might as well at least go as far as 5.8.9 and benefit from other fixes that came from that release also.

And I was also worried about the open file handles in the async thread. I kept imagining the main thread receiving a SIGTERM while the sync thread was trying to write to the file-handle. I believe this is a possibility.

If you are sharing these file handles between threads, then you should be synchronising access to them anyway. Ie. declare a shared variable for use as a mutex, take a lock() on them before printing to them and release it afterward.

Something like:

my $semSTDOUT :shared;

sub tprint{ lock $semSTDOUT; print @_; }
[download]

That's a very simplistic version, but demonstrates the point.

For the 'fire & forget' method, the signal handler would acquire a lock on that semaphore before exiting. That would ensure that none of your other threads could be in the process of writing to the handles when they are forcibly killed.