[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: flushing STDERR and STDOUT more often
From: |
Ole Tange |
Subject: |
Re: RFC: flushing STDERR and STDOUT more often |
Date: |
Thu, 18 Nov 2010 13:50:49 +0100 |
On Thu, Nov 18, 2010 at 1:26 PM, Markus F.X.J. Oberhumer
<markus@oberhumer.com> wrote:
>
> In order to get the same output when redirecting both stdout and stderr to
> the same file (see shell snippet below) I had to apply the following patch
> (against the current git version):
>
>
> diff --git a/src/parallel b/src/parallel
> index 7a770dd..757542e 100755
> --- a/src/parallel
> +++ b/src/parallel
> @@ -4270,12 +4270,14 @@ sub print_job {
> while(sysread($err,$buf,1000_000)) {
> print STDERR $buf;
> }
> + flush STDERR;
> if($Global::debug) {
> print STDOUT "OUT:\n";
> }
> while(sysread($out,$buf,1000_000)) {
> print STDOUT $buf;
> }
> + flush STDOUT;
> debug("<<joboutput $command\n");
> close $out;
> close $err;
>
>
> If these extra flushes might cause a possible performance problem, then
> a compromise could be to limit them to an active $Global::keeporder .
>
> What do you think?
I think it is a bug that the flushes are not there already. This
example shows stderr for A coming after stdout for C, which never was
the intention of GNU Parallel:
parallel -k 'echo stdout{}line;echo -n stderr{}noline 1>&2; echo
stdout{}' ::: A B C
I do not think that one extra flush just before we close will ever be
a performance issue. And I would rather have GNU Parallel do the right
thing slowly than do the wrong thing fast (that is what xargs is for).
/Ole
- Re: RFC: flushing STDERR and STDOUT more often,
Ole Tange <=