A quick inquire to tell when rollover happens:
{SmallInteger maxVal // (24*3600*1000) -> 'days'. SmallInteger maxVal \ (24*3600*1000) // (3600*1000) -> 'hours'. SmallInteger maxVal \ (3600*1000) // (60*1000) -> 'minutes'. SmallInteger maxVal \ (60*1000) // (1000) -> 'seconds'. SmallInteger maxVal \ (1000) -> 'milliseconds'.}. {12->'days' . 10->'hours' . 15->'minutes' . 41->'seconds' . 823->'milliseconds'}
In a Pharo image, I see 112 senders of #millisecondClockValue and only 5 of #millisecondsSince: That let room for future rollover-proof improvments...
First on the list, there are some senders of #deadlineSecs: in HTTPSocket.
Nicolas
2009/4/28 Andreas Raab andreas.raab@gmx.de:
Hi -
I'm not sure anyone cares about this (most likely Seaside users), but class Socket has some issues with clock-rollover which can be seen on high load servers that have enough uptime and load.
The problem is caused by Socket>>deadlineSecs: which at the time of the clock rollover computes a deadline that can never be reached. If you've seen connections that wouldn't time out apparently at random there is a chance you have been affected by this type of issue.
Bug (and fix) are posted at http://bugs.squeak.org/view.php?id=7343
Cheers, - Andreas