bug in gitk on cygwin, v1.5.3-rc1

[Mark Levedahl <mdl123@verizon.net>]

Paul,

The previous bug I reported of gitk giving an error on Cygwin, and that 
you addressed in 8c93917d23ec7ef998154a, now manifests itself 
differently in that all commits are not shown. For instance, "gitk 
v1.5.3-rc1" results in a display where the last shown commit is  9e026d3 
(dated 205-09-26), the tag v0.99.8g is the penultimate shown, both are 
shown with white circles at the tip of their respective commit lines. 
12-15 previous commits are shown in the same way. The correct display of 
course begins with commit e83c51 on 2005-040-7.

I have built a new tcl/tk package, using 8.4.15 sources, using POSIX + 
X-Windows under Cygwin, and using this tcl/tk package I get identical 
(assumed correct) results as I do on my fedora FC7 box. (Such a package 
cannot be introduced into Cygwin as the Tcl/Tk package there is the one 
that supports the insight debugger, and the Tcl/Tk sources are 
integrated into the insight debugger source tree).

Further investigation has shown that:

1) The contents read in getcommitlines is identical (I logged from both 
versions and compared the results).
2) The Posix-X windows version (and on Linux) in general reads 50,000 
bytes at a time from the pipe, as would be expected from the line "    
set stuff [read $fd 500000]"
3) The normal Cygwin TCL version reads 3000 - 5000 bytes at a time, not 
50,000.
4) gitk, prior to commit 8c93917, would throw an error when trying to 
layout the row that now shows up as the last commit.

So, my suspicion is that the layout code gets ahead of the read loop, 
requiring data for a commit not yet read in, and prematurely terminates 
the graph rather than waiting for more data to be read in before 
attempting to continue the layout. Just a guess as I do not really 
understand the pseudo-threading you have written.

Mark Levedahl