Re: Windows support

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: Windows support

From: David Kastrup <hidden>
Date: 2016-06-15 22:43:24

"Nguyen Thai Ngoc Duy" [off-list ref] writes:
On 7/26/07, Johannes Schindelin [off-list ref] wrote:
quoted
Hi,

On Thu, 26 Jul 2007, Nguyen Thai Ngoc Duy wrote:
quoted
I make MinGW busybox part of git for some reasons:

- Making a full MinGW busybox would take lots of time. I don't need
busybox for Windows. What I need is a shell and enough POSIX utilities
to run git shell scripts without any dependencies. Windows users
(including myself when I have to use Windows) hate dependencies.
I think that if you succeed to compile ash on MinGW, the rest is easy.
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.

Would be a fun exercise in particular when merely using
(block-buffered!) pipes, and could presumably make a difference on
multiprocessor-capable machines.

Anyway, just something that had been spinning in my head.  The
"streaming merge" idea has the advantage of keeping memory usage low
pretty much independently of project size: project memory is pretty
much determined by the reader pass since it has to read in a complete
directory level before it can sort it and output the next element, and
it has to retain the not-yet-output elements of the ancestry.

And it is nice to have some potential for parallel processing.  But if
it is a lethal stumbling block for Windows...  It is conceivable to do
the same job instead of with pipes and files with buffers and just
switch manually between the directory scanning and merging phases.
But it would be less fun.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Windows support

From: Nguyen Thai Ngoc Duy <hidden>
Date: 2016-06-15 22:43:24

On 7/26/07, David Kastrup [off-list ref] wrote:
"Nguyen Thai Ngoc Duy" [off-list ref] writes:
quoted
On 7/26/07, Johannes Schindelin [off-list ref] wrote:
quoted
Hi,

On Thu, 26 Jul 2007, Nguyen Thai Ngoc Duy wrote:
quoted
I make MinGW busybox part of git for some reasons:

- Making a full MinGW busybox would take lots of time. I don't need
busybox for Windows. What I need is a shell and enough POSIX utilities
to run git shell scripts without any dependencies. Windows users
(including myself when I have to use Windows) hate dependencies.
I think that if you succeed to compile ash on MinGW, the rest is easy.
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.
I haven't looked at builtin-update-index.c (hey, I'm all doing sh
scripts these days) so no comments here.

-- 
Duy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help