From: Junio C Hamano Date: Wed, 04 Nov 2015 21:01:53 GMT Subject: Re: [PATCHv3 02/11] run-command: report failure for degraded output just once Message-ID: In-Reply-To: <563A6C3D.2050805@kdbg.org> Johannes Sixt writes: > I think that a scenario where A and B are communicating is rather > far-fetched. We are talking about parallelizing independent tasks. I > would not worry. I wouldn't worry too much if this were merely a hack that is only applicable to submodules, but I do not think it is a healthy attitude to dismiss potential problem as far-fetched without thinking things through, when you are designing what goes into the run-command API. I'd grant you that a complete deadlock is unlikely to be a problem on its own. Somewhere somebody will eventually time out and unblock the deadlock anyway. But the symptom does not have to be as severe as a total deadlock to be problematic. If we block B (and other tasks) by not reading from them quickly because we are blocked on reading from A, which may take forever (in timescale of B and other tasks) to feed us enough to satisfy strbuf_read_once(), we are wasting resource by spawning B (and other tasks) early when we are not prepared to service them well, on both our end and on the other side of the connection. By the way, A and B do not have to be directly communicating to deadlock. The underlying system, either the remote end or the local end or even a relaying system in between (think: network) can throttle to cause the same symptom without A and B knowing (which was the example I gave).