From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 27 Jul 2007 21:08:59 GMT
Subject: Re: [PATCH] Make verify-tag a builtin.
Message-ID: <7vtzrpwo44.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <1b46aba20707271251g7cf968a6o3840739dec548408@mail.gmail.com>

"Carlos Rica" <jasampler@gmail.com> writes:

> In my system, some of the tests give 141 and others give 1 as exit code.
> Dscho said that it could depend on the CPU current load of the computer,
> since he got always 141 as you said, so perhaps it's me.

This is expected.  It depends on how processess are scheduled.

What is happening is:

 1. Your process prepares the whole thing in vtag-tmp, to hand
    to gpg;

 2. You make a pipe and start gpg with the above file telling it
    "here is a detached signature file, the payload will be fed
    through your stdin";

 3-a. You feed the payload to the pipe, expecting gpg to read it.

 3-b. gpg reads the detached signature file, finds no signature in
    the vtag-tmp file because the tag in question is not signed,
    and exits without reading a single byte from the pipe;

Now, 3-a and 3-b run in parallel.  If 3-a is scheduled before
3-b happens, because payload is very often much smaller than the
in-kernel pipe buffer, your write(2) succeeds before gpg gives up
and exits without reading from the pipe.  If 3-b is scheduled
before 3-a, then gpg exits and when 3-a gets around to write(2)
to the pipe, write notices that there is nobody on the other end
of the pipe, and you get SIGPIPE.