OSCommerce Product Manager for Windows
FS#322 - Elapsed time checking may give wrong result.
Attached to Project:
OSCommerce Product Manager
Opened by Mario A. Valdez-Ramirez (mvaldez) - Wednesday, 05 April 2006, 01:57 GMT
Last edited by Mario A. Valdez-Ramirez (mvaldez) - Saturday, 21 July 2007, 09:52 GMT
Opened by Mario A. Valdez-Ramirez (mvaldez) - Wednesday, 05 April 2006, 01:57 GMT
Last edited by Mario A. Valdez-Ramirez (mvaldez) - Saturday, 21 July 2007, 09:52 GMT
|
DetailsAt several places, specialy when waiting for a retry, the application check the current time (with milisec resolution) and it act accordingly. The usual checking is done with a GetTickCount functions.
We are aware of a possible problem if the computer (client-side, not server) is left running more than 49.7 days. The GetTickCount will be restarted. We usually do this: LapseTime := GetTickCount; REPEAT Application.ProcessMessages; UNTIL ((GetTickCount - LapseTime) > opmG_HTTPConnWait); The problem will happen if we start the loop and then the GetTickCount value is wrapped (restarted), the loop would take 49.7 days to complete (unless again it wraps before the cheking, which would extend the wait for 49.7 days). Even though this would be a very rare occurrence, it should be fixed. |
This task depends upon
He he he. Microsoft recommends using GetTickCount64. The only detail it is that it is only available in Windows Vista. Funny guys.
LapseTime := GetTickCount;
REPEAT
Application.ProcessMessages;
UNTIL (((GetTickCount - LapseTime) > opmG_HTTPConnWait) OR (GetTickCount < LapseTime));
In this way, the second condition in the UNTIL will check if GetTickCount is lower than LapseTime (the starting time). GetTickCount will be always higher than LapseTime, unless it overflows and wrap arount to zero again. If that happes, the waiting time will be lower than expected, but that is far more better than freezing in a 49-days loop.