Re^3: Hang on STDOUT

[BrowserUk]

it is possible that two different threads might try to write to STDERR

If you're not using locking on global handles that can be used from multiple threads, you should be.

Ie.

use threads::shared;
...
my $sem :shared;

...

{ # some scope (as tight as possible)
    lock $sem;
    print ...;
}

Or better:

use threads::shared;

my $semSO :shared;
sub tprint  { lock $sem; print  @_; }
sub tprintf { lock $sem; printf @_; }

my $semSE :shared;
sub twarn{  lock $semSE; print  STDERR @_; }
sub twarnf{ lock $semSE; printf STDERR @_; }

...
tprint( $some, "Stuff" );
...

else twarnf( "%u %s\n", $this, $that );

You might also consider using just one semaphore for both stdout and stderr if the are habitually directed to the same place.

Not saying this will fix your (exceptionally vaguely described) problem; but at least it will be one possibility removed from consideration.