On Saturday 21 July 2012 10:44:37 Jonathan Nieder wrote: > Florian Achleitner wrote: > > On Saturday 21 July 2012 09:48:34 Jonathan Nieder wrote: > >> To sum up: I think we should just stick to pipes --- why all this fifo > >> complication? > > > > People didn't like pipe variant (prexec_cb not being compatible to > > windows' > > process creation model), so I learned about fifos and implemented a > > (basic) fifo variant. *shrug* > > Ok, can you elaborate on that? What does it mean that preexec_cb is > not compatible to windows' process creation model? Don't the people > of the future working on this code deserve to know about that, too, so > they don't break it? Let's discuss how to describe the solution after we decide which of the two variants we choose. Summarizing the earlier discussion (in this thread as replies to version 1 of the patch) more verbosely: I used the prexec_cb feature of start_command which allows to install a callback function that is called just before exec. It's purpose is to close the other pipe end in each of the processes that inherited both ends after fork. The pipe is created in transport-helper.c, because it forks fast-import as well as the remote-helper, which inherit the pipe's file descriptors. On Windows, processses are not forked but spawned from new and therefore can't inherit pipe file descriptors. So we had the idea to use a fifo, which can be opened after the creation of the process. Also there are named pipes on Windows which are similar to fifos (though I've never used them). Mostly out of curiosity I played around with fifos and implemented this additional cat-blob-pipe feature, like a proof-of-concept. The first version used the pipes because this feature already exists. > > Come on --- I'm not asking these questions just to make your life > difficult. Please make it easy to understand your code changes and to > keep them maintained. The reason why I resent the patch in version 3 these days is that I the problem of blocking open calls leading to potential deadlocks. Of course I should tell future maintainers better what its all about, if we really want that feature. Hope that helps, Florian -- 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