Hang on STDOUT

DanEllison has asked for the wisdom of the Perl Monks concerning the following question:

I'm using Strawberry Perl in a Windows 8 environment. I have a scheduler I have written in Perl that I have been using for a couple of years. Its a threaded application that runs more than 1500 jobs every night, so its doing a lot of the same thing over and over.

The main engine spawns worker threads to run the individual jobs and reports some progress to STDOUT. I have had issues in the past where STDOUT would somehow get corrupted and the engine would stop reporting progress but continue to run and I would eventually find my progress messages in one of the job log files.

I haven't seen that issue in a while, but lately I find the engine has simply hung. It writes messages to both STDOUT and to a log file, and I've been adding debugging left and right, and it simply appears to be hanging on prints to STDOUT.

Autoflush is on and I can see single character updates, but here's an example:

sub message {
    if ($options{verbose} && $options{verbose} >= ($_[1] || 0)) {
        if ($inprogress) { print "\n"; $inprogress = 0; }
        print "<";
        my @time = localtime;
        print ">";
        printf "%04d-%02d-%02d %02d:%02d:%02d %s\n", $time[5] + 1900,
            $time[4] + 1, $time[3], $time[2], $time[1], $time[0],
            $_[0];
    }
}
[download]

$_[0] is the message I want to print. I thought maybe I was hanging trying to get the local time, but no. I put the < and > prints on either side of the localtime, but it hung between the > and the printf of the message.

Has anyone had experience with this?

Comment on Hang on STDOUT Download Code

Replies are listed 'Best First'.
Re: Hang on STDOUT by BrowserUk (Patriarch) on Jul 02, 2015 at 13:27 UTC
Its a threaded application Are you printing to stdout from multiple threads? 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!	[reply]
Re^2: Hang on STDOUT by DanEllison (Scribe) on Jul 02, 2015 at 13:53 UTC
Unlikely. However it is possible that two different threads might try to write to STDERR.	[reply]
Re^3: Hang on STDOUT by BrowserUk (Patriarch) on Jul 02, 2015 at 14:09 UTC
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. 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!	[reply] [d/l] [select]
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
Re^5: Hang on STDOUT by BrowserUk (Patriarch) on Jul 02, 2015 at 17:25 UTC
Re: Hang on STDOUT by graff (Chancellor) on Jul 02, 2015 at 23:16 UTC
When the process is running, where does its STDOUT go? Is it being redirected to a file, or piped to some other process? (If it's just spilling into a terminal window, you might as well not be printing to STDOUT at all.) In either case, have you checked the status of the recipient? (The process would naturally have to wait if it couldn't write to STDOUT, e.g. because of an input-buffer-full condition on a downstream pipeline process.)	[reply]