Thread (2 messages) 2 messages, 2 authors, 2020-11-26

Re: Bug report: orphaned pack-objects after killing upload-pack on [

From: Jeff King <hidden>
Date: 2020-11-26 00:53:30

Possibly related (same subject, not in this thread)

On Wed, Nov 25, 2020 at 01:42:24PM -0800, Junio C Hamano wrote:
quoted hunk ↗ jump to hunk
In the meantime, I may queue this on 'seen' but it cannot move
forward without a signoff.

Thanks.

--- >8 ------ >8 ------ >8 ------ >8 ------ >8 ---
From: René Scharfe <redacted>
Date: Fri, 20 Nov 2020 19:52:45 +0100
Subject: [PATCH] upload-pack: kill pack-objects helper on signal or exit

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, the pack-objects will hang around as a zombie.  We should
take it down when we go down.
I think this is a good thing to do. I'd probably avoid the word "zombie"
here, though. The orphaned pack-objects does not become a zombie process
in the traditional Unix sense of the word, waiting to be reaped by a
parent which is not paying attention. Instead it is still running but
doing work for a caller that will never read the result.

So maybe:

  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.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help