Re: [PATCH] Make verify-tag a builtin.

"Carlos Rica" [off-list ref] 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.

Your explanation about the I/O in parallel sounds much better to me,
now I understand, thank you Junio.

2007/7/27, Junio C Hamano [off-list ref]:

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.