"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:

quoted text
> On 7/26/07, David Kastrup <dak@gnu.org> wrote:
>> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html