Am 26.11.20 um 02:04 schrieb Junio C Hamano:

Jeff King [off-list ref] writes:

quoted

On Wed, Nov 25, 2020 at 01:42:24PM -0800, Junio C Hamano wrote:

quoted

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.)

René