parallel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]