Mantis Bugtracker
  

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
Reporter tim View Status public  
Assigned To ducasse
Priority high Resolution fixed  
Status closed   Product Version 3.8
Summary 0001840: Long Delays and multiple delays with same resumption time
Description 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:[
        ActiveDelay signalWaitingProcess.
        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().
Additional Information 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

- Relationships
related to 0000854closed  Long Delay schedules a deferred image crash 
related to 0005245closed mikevdg Delay class>>primitiveFailed 

- Notes
(0002915 - 183 - 183 - 183 - 183 - 183 - 183)
tim
10-20-05 00:54

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)
tim
04-22-06 01:39

Reminder sent to: ducasse

Stef, can you check this, or pass it on, or something?
 
(0004822 - 45 - 57 - 57 - 57 - 57 - 57)
ducasse
04-29-06 21:59

ok will put it in the next batch 7026

Stef
 
(0004823 - 20 - 20 - 20 - 20 - 20 - 20)
ducasse
04-29-06 22:16

in 3.9 7026 normally
 

- Issue History
Date Modified Username Field Change
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.
Powered by Mantis Bugtracker