Am 26.11.20 um 02:04 schrieb Junio C Hamano: > Jeff King <peff@xxxxxxxx> 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é
