From: "René Scharfe" <email@example.com> To: Junio C Hamano <firstname.lastname@example.org>, Jeff King <email@example.com> Cc: 唐宇奕 <firstname.lastname@example.org>, email@example.com 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: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> Am 26.11.20 um 02:04 schrieb Junio C Hamano: > Jeff King <firstname.lastname@example.org> 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.) René
next prev parent 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: 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Bug report: orphaned pack-objects after killing upload-pack on [' \ /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
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git 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).