git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: "René Scharfe" <l.s.r@web.de>
To: Johannes Sixt <j6t@kdbg.org>, Chris Torek <chris.torek@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] midx: use buffered I/O to talk to pack-objects
Date: Tue, 4 Aug 2020 00:27:35 +0200
Message-ID: <fdf66f66-b7ed-f733-22d0-23ec17209f40@web.de> (raw)
In-Reply-To: <1fd18b0c-8c2c-54ab-89aa-357b046eb403@kdbg.org>

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@web.de> 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é


  reply	other threads:[~2020-08-03 22:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-02 14:38 René Scharfe
2020-08-02 16:11 ` Chris Torek
2020-08-03 18:10   ` Johannes Sixt
2020-08-03 22:27     ` René Scharfe [this message]
2020-08-04  4:31       ` René Scharfe
2020-08-04  4:37         ` Junio C Hamano
2020-08-03 12:39 ` Derrick Stolee
2020-08-11 16:08   ` René Scharfe
2020-08-11 17:14     ` Derrick Stolee
2020-08-12 16:52 ` [PATCH v2] " René Scharfe
2020-08-12 20:28   ` Junio C Hamano
2020-08-12 20:31     ` Junio C Hamano
2020-08-13  9:11       ` Jeff King
2020-08-13  9:06     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fdf66f66-b7ed-f733-22d0-23ec17209f40@web.de \
    --to=l.s.r@web.de \
    --cc=chris.torek@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git