Experiment: track and wrap Timers and run* blocks in the clock control zone. #9080
Conversation
|
This breaks 6 of 8 tests without the timer triggered delay from #9069. If the However, it fixes the fragile task_test.dart in #9069, though the wall-clock time rises to ~90-100 seconds to run all 8 tests. It turns out that the tests will create roughly ~171k timer instances, of which ~57k will be clock-controlled timers (33%). Maybe we could do smarter re-entry detection and possibly separate the control zone of the ClockControl from the execution zone, I'm not sure if it is worth the effort to look into this further. |
app/lib/task/clock_control.dart
Outdated
| final current = StackTrace.current.toString(); | ||
| if (current.contains('ClockController._createTimer') || | ||
| current.contains('ClockController._triggerPendingTimers') || | ||
| current.contains('ClockController._cancelPendingTimer')) { | ||
| return parent.createTimer(zone, duration, f); | ||
| } | ||
| final clockCtrl = zone[_clockCtrlKey]; | ||
| if (clockCtrl is ClockController) { | ||
| return clockCtrl._createTimer(duration, f); | ||
| } else { | ||
| return parent.createTimer(zone, duration, f); | ||
| } |
There was a problem hiding this comment.
I think this is remarkably brave, and what does this do?
There was a problem hiding this comment.
The first few lines detects if the timer is created inside the ClockControl's internal timer-related methods or outside of it, and if inside, we return the default timers.
I think this part could be much smarter, e.g. ClockControl should create these timers outside of the current zone, maybe in the root zone.
The next part is a sanity check: if we are inside the clock-controlled zone (which we always should be as we fork it inside of it), and creates a timer that is both an internal object we use to track and elapse, and an implementation of Timer which can be returned (so that the caller may cancel it, also removing it from the tracking).
|
Note: the new version takes about 1 minute to run the task_test.dart with the delayed datastore ops from #9069. |
|
The periodic timer implementation may be a bit sub-optimal, but seems to work in both at HEAD and in #9069. I think this could be an acceptable way of writing time-control tests, but I would also refactor/expose the loop internals and make them independently testable. |
2 participants
No description provided.