[Pythonmac-SIG] BitTorrent on Mac OS 9: redux

[Phil]

Howdy,

Some folks on the list may remember a thread, from a little more than a
year ago
(http://mail.python.org/pipermail/pythonmac-sig/2004-April.txt.gz), where I
asked the following question:

"I'm trying to track down a bug that shows up when I run
BitTorrent for Mac OS 9, and I'm not sure whether it's a problem with
BitTorrent, MacPython, or some combination of both...in BitTorrent, when
you resume downloading after having stopped (say, to restart your
computer), the
client checks the portion of the file you've already downloaded.  (I assume
it does this to test for corruption and so forth.)  Normally, under Windows
or OS X, this takes just a few minutes.

"But for some reason, under OS 9, it takes an absurd amount of time --
something like 1 hour per 100 MB.  From what I understand, "checking [the]
existing file" is _not_ a computationally-intensive process, and shouldn't
take anything like the length of time it takes on Mac OS 9 (using the
btdownloadheadless.py client, which is the only one that works under OS 9).
As it stands now, if I'm interrupted near the end of an 800MB download, I
have to let my computer run overnight just to get back on!"

At the time, several list members were kind enough to offer suggestions,
through which we established a few things:

-- Quitting all other open programs -- including the Finder -- doesn't help.
-- Increasing the memory allocated to MacPython doesn't help.
-- The problem doesn't seem to have anything to do with virtual memory.

Alas, between the lack of data and my own lack of Python skills, we didn't
get much further.  For want of a solution, I borrowed a Windows computer
and did my BitTorrent-ing on that machine.

And so the matter has rested for the past year. However, I've just resumed
using my OS 9 machine to participate in torrents, and recently, I
discovered an important data point that may shed light on the problem.  If
I may elaborate:

While btdownloadheadless.py is "checking existing file", the MacPython
window normally updates every eight seconds or so, changing the "percent
done" to reflects how much is left to check.  On a file of, say, 250MB,
that "percent done" changes by an average of 0.1% every update -- which
means that checking the whole file takes about 8000 seconds, or 2+ hours.

However, if you resize the MacPython window by clicking the lower-right
hand corner, it updates *immediately*.  And if you resize the window
constantly, clicking on the lower-right corner over and over again, it
updates nearly as fast as you click it [1] -- at the minimum, you can get
it to update once per second, which means that it's checking the file about
eight times as fast as it would otherwise be (at the expense of your having
to sit there, clicking hundreds of times!).  It's still not as fast as on
Windows, where it takes mere seconds -- but cutting the amount of time it
takes from 150 minutes, to 20 or fewer, would still be huge.

So, does this information make anyone go "Aha!", by any chance?  It seems
to me that it's now unambiguously clear that the problem is not a processor
bottleneck, but something else entirely.  I'm no programmer, but I'm
guessing that something about resizing the window (you don't actually need
to resize it, but only to "attempt" to, if that makes sense) is either (a)
encouraging the OS to give a higher priority to MacPython, or (b)
jump-starting MacPython into performing an operation that it's otherwise,
for unknown reasons, deferring.

If anyone has any thoughts on this, I'd love to hear them, and will be
grateful for your willingness to grapple with an obscure bug on an outdated
OS.  It's not an earth-shakingly important problem, but it'd be awesome if
there's a solution!

Thanks,
Phil

[1]  Footnote:  the optimum rate seems to be to click the window, and
resize it, immediately after it scrolls and updates -- slightly faster than
once per second -- and in a steady rhythm.  Doing it faster doesn't do any
good.