|
|
This is my long promised cleanup of the delay scheduling system. I've been polishing some minor points for a few months and its time to put it out for review.
My original refactoring of the class-side code inherited from Squeak had left alone the mutex variable in parent class even though it was no longer used.
Now at the top level there is DelayNullScheduler which does nothing but define the minimum interface required to prevent errors in the rest of the system.
Subclassed from that is DelayBasicScheduler which provides the main algorithm without synchronization protection. This works fine but is fragile to changes in process scheduling semantics.
Subclassed from that are two classes add synchronization: DelayMutexScheduler and DelaySemaphoreScheduler.
I hope this arrangement helps highlight the separate aspects of the system.
I believe the existing code has a risky possible corner case related to suspending the delay scheduler for shutDown during a snapshot.
The Its accessProtect mutex only protects against blocks calls from user code and not from the VM waking up the timingPriority loop to potentially expire delays at a higher priority than the snapshot process.
I've replaced that with semaphore immediately following the timingSemaphore suspension point in #timingPiorityRunEventLoop to guarantee the a VM can't wake up the loop can't signal expired delays .
Previously some unit tests were a bit awkward in how they interfered with the system's active delay scheduler.
I've extracted the VM interaction code into separate DelayMicrosecondTicker and DelayMillisecondTicker
plus associated simulation classes for use by tests. I've kept the millisecond option since it may be beneficial for future embedded 32-bit platforms. Also some of the delay scheduling tests relied on measuring the progress of real time and thus perhaps were fragile on CI servers causing false failures. It should be much more robust now that time is simulated.
A nice side-effect of separation is highlighting that the main algorithm is independent of a particular time-base.
In the back of my mind I'm playing with an idea that when multi-threaded callbacks are implemented, this separation of "ticker" might
help experiment with wakeup ticks coming directly from native timers rather than a loop in the VM checking the time.
@holger, I've refactored your DelayTickerlessScheduler into DelayUnconstrainedTicker. Could you take a particular focus on reviewing that part?
I fear I've made the ticker simulation too complex. To help reviewers follow the multi-threaded interactions I've left in some conditional debug breakpoints
which can be enabled before running tests by manually evaluating a line in TestDelayBasicSchedulerMicrosecond>>setDebugOnOff .
You just need to be careful not to step <Over> any #wait or the system hangs. Use <Proceed> instead.
I've not removed the old hierarchy yet, so these changes can be evaluated in an existing image.
I need advice on any coupling this has with the bootstrap process.
|
|
|
Priority: 3 – Must Fix
|
|
Status: Work Needed
|
|
Assigned to: Everyone
|
|
Milestone: Later
|
Go to Case
|
|
Locked
Debugging: 1. Pharo Image
• You are subscribed to this case
