|Anonymous | Login||09-26-2021 13:10 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0001840||[Squeak] Kernel||major||always||10-05-05 01:32||04-29-06 22:16|
|Summary||0001840: Long Delays and multiple delays with same resumption time|
Mantis 0000854 made a small improvement in Dealys by preventing long delays. That isn't very helpful when you actually need long delays.
With a little change to the delay prim error handling code we can make a fake Delay to place-hold the timer and reschedule very long delays when a Delay with a resumption time that is > SmallInteger maxVal is scheduled. The long delay will get gradually whittled down to a VM acceptable value as the clock rollover code does its job. The fake Delay does nothing when it triggers.
I also propose a small optimisation to the clock rollover code in Delay class>timerInterruptWatcher to avoid using the rather over-done saveResumptionTimes/restoreResumptionTimes pair. Since weknow the ActiveDelay is due, that it exists, that it has already fired, we can forget messing with assorted tests and recalculations of its resumption time.
Further, I note that Delay>activate ought to use a >= test insted of > in the phrase:-
ActiveDelayStartTime > resumptionTime ifTrue:[
SuspendedDelays isEmpty ifTrue:[
The VM triggers delays at the tick that they are supposed to go off. Thus we go into timerInterruptWatcher with time T and fire the active delay. Then the next suspended delay is pulled off the list and acivated - which checks to see if it should be fired immediately. IF this new delay is supposed to have the same resumption time as the one just fired, we should be firing it and going for a third one - and so on. However, the use of '>' means that the delay will be held back by at least 1mS and will be scheduled to the VM where it's resumption time will get caught at the next checkInterrupts().
A special OSX VM with a clock limited to 8k-1 and a similar value in the beGuardianDelay has shown that this seems to work ok.
After some looking over by other interested parties this ought to replace (winth some extra code to suit) the 00854 changes
|Attached Files||LongDelayFixes-tpr.2.cs.gz [^] (1,877 bytes) 10-05-05 01:36|
(0002915 - 183 - 183 - 183 - 183 - 183 - 183)
|You have the baton for Kernel stuff right now so I'd like your opinion on this suggested change. I beleive it to be much better than the rather frail change previously offered in 0854|
(0004770 - 55 - 55 - 55 - 55 - 55 - 55)
Reminder sent to: ducasse
Stef, can you check this, or pass it on, or something?
(0004822 - 45 - 57 - 57 - 57 - 57 - 57)
ok will put it in the next batch 7026
(0004823 - 20 - 20 - 20 - 20 - 20 - 20)
|in 3.9 7026 normally|
|10-05-05 01:32||tim||New Issue|
|10-05-05 01:33||tim||Relationship added||related to 0000854|
|10-05-05 01:36||tim||File Added: LongDelayFixes-tpr.2.cs.gz|
|10-20-05 00:54||tim||Note Added: 0002915|
|10-20-05 00:54||tim||Assigned To||=> ducasse|
|10-20-05 00:54||tim||Status||new => feedback|
|02-19-06 23:32||lewis||Issue Monitored: lewis|
|04-22-06 01:39||tim||Note Added: 0004770|
|04-29-06 21:59||ducasse||Note Added: 0004822|
|04-29-06 22:16||ducasse||Status||feedback => closed|
|04-29-06 22:16||ducasse||Note Added: 0004823|
|04-29-06 22:16||ducasse||Resolution||open => fixed|
|10-17-06 04:02||tim||Relationship added||related to 0005245|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
65 total queries executed.|
44 unique queries executed.