Re: [PATCH] midx: use buffered I/O to talk to pack-objects

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 03.08.20 um 20:10 schrieb Johannes Sixt:
> Am 02.08.20 um 18:11 schrieb Chris Torek:
>> On Sun, Aug 2, 2020 at 7:40 AM René Scharfe <l.s.r@xxxxxx> wrote:
>>> @@ -1443,10 +1446,15 @@ int midx_repack(struct repository *r, const char *object_dir, size_t batch_size,
>>>                         continue;
>>>
>>>                 nth_midxed_object_oid(&oid, m, i);
>>> -               xwrite(cmd.in, oid_to_hex(&oid), the_hash_algo->hexsz);
>>> -               xwrite(cmd.in, "\n", 1);
>>> +               fprintf(cmd_in, "%s\n", oid_to_hex(&oid));
>>> +       }
>>> +
>>> +       if (fclose(cmd_in)) {
>>> +               error_errno(_("could not close stdin of pack-objects"));
>>> +               result = 1;
>>> +               finish_command(&cmd);
>>> +               goto cleanup;
>>>         }
>>> -       close(cmd.in);
>>>
>>>         if (finish_command(&cmd)) {
>>>                 error(_("could not finish pack-objects"));
>>> --
>>> 2.28.0
>>
>> Here, we don't have any explicit errno checking, but
>> of course error_errno() uses errno.  This too needs
>> an ferror() (or fflush()) test before the final fclose(),
>> and then we just need to use plain error().  Otherwise
>> you'll need the clumsier test-after-each-fprintf() and
>> an explicit final fflush()-and-test.

OK, the implicit fflush() called by fclose() and thus fclose() itself
can succeed even if the error indicator is set, in particular if that
fflush() has nothing to do.  So we need to check ferror() before calling
fclose().

If ferror() tells us there was an error, errno might contain some random
error code, but not necessarily the root cause.  Thus we better keep
quiet about it and only use error() to tell the user we failed to talk
to our child but we don't know why.

We could fflush() explicitly before fclose(), but fclose() reports any
failure of its implicit fflush() anyway , so we don't gain anything by
doing so.

Did I get that right?

> We need this explicit test after each fprintf anyway because SIGPIPE may
> be ignored, and then writing fails with EPIPE. On Windows, this is
> doubly important because we do not have SIGPIPE at all (and always see
> EPIPE), but we see EPIPE only on the first failed write; subsequent
> writes produce EINVAL.

Why is this important?  The current code doesn't care about it, at
least.  It does care about EINTR, though.

René





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux