A fix for the smalltalk bug is to make sure that the timeout calculation similarly rolls over. i.e.
deadlineSecs: secs "Return a deadline time the given number of seconds from now."
^ (Time millisecondClockValue + (secs * 1000) truncated) \ SmallInteger maxVal.
The code in question does not use Socket-#deadlineSecs: and there are many many places in the image that could be caught by this. The solution is to put this code on Time and encourage its use.
Time-deadlineSecs: Time-pastDeadline: deadline
of course if your millisecondClock has got stuck then its a vm problem
Keith
If the millisecondClock is close to rolling over then the deadline may be set in the future to a number greater than SmallInteger maxVal and timeouts will never complete.
For Socket the default timeout is 45 seconds. So thinking about it this error is only likely to occur for 45 seconds every 12 days or so, but it will occur if there is code which relies upon the timeout itself.
Now this is a complete guess but it might be your explanation. What if somehow your millisecond clock has failed to roll over and might be stuck in that dangerous region ie. at SmallInteger maxVal.
Keith
___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" – The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html
___________________________________________________________ All New Yahoo! Mail – Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html