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 ...;
}
[download]

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 );
[download]

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.

Greetings,

I tested BrowserUk's example using a semaphore lock and sometimes fail on macOS; even with auto flush enabled. I thought that this would work but is not consistent on macOS that is. Two of the lines were combined into one super long line.

Be sure to direct the output to STDERR when testing; i.e. 2>output.txt on UNIX. The output file is 3.4 GiB.

use strict;
use warnings;
use threads;
use threads::shared;

# enable autoflush on the handle
STDERR->autoflush;

my $sem_stderr :shared;
sub print_err { lock $sem_stderr; print STDERR @_; }

sub task {
    my $id = shift;
    my $str = "ab " x 3000;
    for (1..10000) {
        print_err($str, "\n");
    }
}

threads->create('task', $_) for 1..40;
$_->join for threads->list;
[download]

MCE::Shared was released some time after BrowserUk's response. Using MCE::Shared, auto flush is enabled behind the scene during construction. This example runs consistently without garbled output.

use strict;
use warnings;
use threads;
use MCE::Shared;

mce_open my $err_fh, '>>', \*STDERR;

sub task {
    my $id = shift;
    my $str = "ab " x 3000;
    for (1..10000) {
        print $err_fh $str, "\n";
    }
}

threads->create('task', $_) for 1..40;
$_->join for threads->list;
[download]

Does your Perl binary lack threads support? If yes, MCE::Shared also works with child processes. Here is the same thing using MCE::Hobo.

use strict;
use warnings;
use MCE::Hobo;
use MCE::Shared;

mce_open my $err_fh, '>>', \*STDERR;

sub task {
    my $id = shift;
    my $str = "ab " x 3000;
    for (1..10000) {
        print $err_fh $str, "\n";
    }
}

MCE::Hobo->create('task', $_) for 1..40;
$_->join for MCE::Hobo->list;
[download]

md5sum and word count:

MD5 (output.txt) = b5bf2b49acd0926a9fa156def91579a0
400000 1200000000 3600400000 output.txt
[download]

Regards, Mario

True, and easy enough. I'll try to eliminate any possibility of a collision.

your (exceptionally vaguely described) problem

Yes, I know. During 8 hours of processing, it may hang once or twice, and seemingly different locations. If I could describe it any better, it wouldn't be a problem.

If I could describe it any better, it wouldn't be a problem.

I appreciate that it can be hard to track these sort of things down.

One thing I would try is replace the printf with sprintf to a variable, and the print the variable and put another trace between the two.

Ie. Try and eliminate whether it is the formatting or the IO that's hanging up.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!