in reply to Re^2: Hang on STDOUT
in thread Hang on STDOUT
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.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^4: Hang on STDOUT
by marioroy (Prior) on Dec 28, 2020 at 22:58 UTC | |
Re^4: Hang on STDOUT
by DanEllison (Scribe) on Jul 02, 2015 at 16:47 UTC | |
by BrowserUk (Patriarch) on Jul 02, 2015 at 17:25 UTC |