Johannes Sixt <j6t@xxxxxxxx> 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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html