On Sun, 30 Apr 2000 19:51:28 -0400 (EDT) Doug Way <dway at mat.net> wrote:
>I happened to try using "update from server" to update a Squeak 2.7 image
>to 2.8alpha.
>
>For updates 1765 to 1799, there is about a 2 second delay between the time
>one progress bar dissappears and the next one appears.  But after update
>1800, the delay jumps up to about 20 seconds between every update.  This
>is on Windows NT.
>
>But I tried updating from the exact same image on SGI/Irix, but it's fine,
>the delay stays at about 2 seconds between updates.
>
>Then I figured I might as well try my Mac at home (with a 56K modem), and
>it seems to have the same problem that Windows has.  Weird.
>
>I did a alt-. during the 20 seconds, and it's sitting in
>Semaphore>>waitTimeoutMSecs:, where msecs is 20000. (kind of makes sense)
>
>(On Windows NT, I also tried updating from a saved 2.8alpha image which
>happened to start at update 1919... this one only had 2 second delays.)
>
>Anyway, the problem is pretty annoying... basically, if you try to update
>a 2.7 image to 2.8alpha on Windows or a Mac, it takes a *long* time, about
>90 minutes longer than it should.

Hi Doug,

What I see is this:

cs 1800 includes in its postscript

	Smalltalk recreateSpecialObjectsArray.

which effectively eliminates the VM's knowledge of where the semaphore for NetNameResolver is. As a result, even though subsequent NetNameResolver requests for the address of the server containing the updates succeed, the VM doesn't know whom to notify. Thus the full 20 second wait happens before NNR sees the success.  don't see a real pretty solution, but one thaing that helps is

changing

			ResolverSemaphore waitTimeoutMSecs: (deadline - Time millisecondClockValue).

to 

			ResolverSemaphore waitTimeoutMSecs: 100.

in the following:

	NetNameResolver class>>waitForResolverReadyUntil:
	NetNameResolver class>>waitForCompletionUntil:

An alternative would be for cs 1800 to use something a little less drastic than #recreateSpecialObjectsArray since the goal in this case is to *add* information, not to *remove* it.

Cheers,
Bob