Hi Wayne,
Thanks for the ideas, I will give it some thought. Unfortunately, for me, I can't think of many if any. There could be some hidden synchronous callouts made by the VM but I would expect they would be made is a way that wouldn't block the whole VM. I'm careful to put anything that would take a while, synchronous callout or not, in its own fork. And nothing I do should take minutes. That's why I wonder if there isn't something interfering with the dispatching of the VM or the VM;s dispatching of forks?
I have seen something like this in the past. On a system running under I think VMWare, when a VA Smalltalk GUI program of mine is set to run at above normal Windows priority, the whole system slowed to a crawl. Especially the GUI program that I was trying to get to run a little faster. Setting the Windows priority to normal, eliminated the problem (no other change what so ever).
Now, my current problem isn't on a system running under VMWare but I'm sure the environment can have an effect. Also, as I said, the Smalltalk code (mine) is basically the same between the systems built with V5.5.2 and V8.0.3. Now the Smalltalk VMs are different, some DLLs are different and the load is different (the lighter the load the WORSE the problem, I'm not sure the problem even exists on the V5.5.2 system).
Lou