"Nguyen Thai Ngoc Duy" <pclouds@xxxxxxxxx> writes: > On 7/26/07, David Kastrup <dak@xxxxxxx> wrote: >> "Nguyen Thai Ngoc Duy" <pclouds@xxxxxxxxx> writes: > >> > No it's not. With a couple of ifdefs you can compile it fine. Then >> > there goes fork(), fcntl(F_DUPFD), /dev/*, job/signal handling... >> > Fortunately Git does not use lots of features. It only needs >> > /dev/null (and /dev/zero for tests), SIGEXIT and no job usage.. That >> > cuts down the effort porting ash. >> >> And here I was tempted to multithread builtin-update-index.c: it is >> actually quite natural to let one process scan directories >> non-recursively, stat the files, sort them on a per-directory grain >> and feed a sorted pseudo-index into a pipeline (recursing to scanning >> whenever hitting a directory), then let another process/thread do a >> merge-pass of pseudo-index and real index, immediately writing the >> output to a new index-to-be. When this is finished and another >> process invalidated the old index already, reuse the index-to-be as >> pseudo-index and merge it with the new-index-which-got-in-ahead-of-me. >> > (snip) > > If you are going to do it. I suggest to base on official mingw > branch. Why would I do that? I am not using Windows. Since Windows NT was flaunting threads big style years before Linux, I should not think this implementation approach really to be a major porting hurdle, at least if one indeed uses pipes for the IPC. It should actually be doable with a clone system call or pthread_create, whatever is easier to translate into Windows semantics. The latter probably is more portable nowadays. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum - 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
