mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "René Scharfe" <>
To: Junio C Hamano <>, Jeff King <>
Cc: 唐宇奕 <>,
Subject: Re: Bug report: orphaned pack-objects after killing upload-pack on [
Date: Thu, 26 Nov 2020 21:04:35 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Am 26.11.20 um 02:04 schrieb Junio C Hamano:
> Jeff King <> writes:
>> On Wed, Nov 25, 2020 at 01:42:24PM -0800, Junio C Hamano wrote:
>>> In the meantime, I may queue this on 'seen' but it cannot move
>>> forward without a signoff.
>>>  ...
>>   We spawn an external pack-objects process to actually send objects to
>>   the remote side. If we are killed by a signal during this process,
>>   then pack-objects may continue to run. As soon as it starts producing
>>   output for the pack, it will see a failure writing to upload-pack and
>>   exit itself. But before then, it may do significant work traversing
>>   the object graph, compressing deltas, etc, which will all be
>>   pointless. So let's make sure to kill as soon as we know that the
>>   caller will not read the result.
> Thanks, that reads well.

The patch is trivial, you don't need my sign-off.  You could record Peff
as its author, as he contributed the most to the version in seen.

Before I could submit that one (or something similar) formally, I'd need
to understand what's happening here a lot better and witness the effect
of the patch.

I understand that the main benefit of stopping the child upon
termination of the parent is to avoid using CPU cycles on a heavy task
whose results will just go to waste.  But wouldn't the orphaned child
then become a zombie?  Init would reap it eventually, but are there
perhaps init-less deployments (containerized daemon?) where such
zombies could pile up?

For a test, winning the race condition should be easy if we cheat by
letting the child loop forever.  But I struggle even with the most
basic task: Making upload-pack invoked by clone call pack-objects.
(Feeling a bit silly.)


  reply	other threads:[~2020-11-26 20:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-19  8:18 唐宇奕
2020-11-20 18:52 ` Bug report: orphaned pack-objects after killing upload-pack on [was: (no subject)] René Scharfe
2020-11-21  0:29   ` Jeff King
2020-11-21 21:54     ` Bug report: orphaned pack-objects after killing upload-pack on [ Junio C Hamano
2020-11-24  3:21       ` 唐宇奕
2020-11-24  9:11       ` Jeff King
2020-11-25 21:42         ` Junio C Hamano
2020-11-26  0:53           ` Jeff King
2020-11-26  1:04             ` Junio C Hamano
2020-11-26 20:04               ` René Scharfe [this message]
2020-11-27  4:17                 ` Jeff King
2020-11-27 20:43                   ` René Scharfe
2020-11-28  6:30                     ` Jeff King
2020-12-01 12:15                 ` Jeff King
2020-12-02 11:45                   ` René Scharfe
2020-12-02 22:14                     ` Junio C Hamano

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:

  List information:

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

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).