On Fri Aug 16 16:49:19 2024 +0000, Gabriel Ivăncescu wrote:
Why do you need to store an info if a timer was blocked? All you need
to know is if there are any timers that need to be processed, for which comparing time stamps would be enough. Well without that we'd get spurious SetTimer calls even if the timer wasn't actually killed, which will happen a lot (on every task almost in common case). Is that fine? I didn't want to mess with the original timer. I wasn't sure if it loses resolution or something. e.g. timer in 50ms, we process a task that takes 2ms (probably more than usual already), then we SetTimer again on it because list isn't empty, possibly back to 50ms? (depends on tick count granularity). With the patch the timer was never killed so it won't SetTimer on it.
I don't think it has to be done in this MR and I'm sure it doesn't
need to be a massive single commit. It looks questionable in its current form, but I didn't look deeper into that. I could split it but it is necessary unfortunately. Note that for the tests to pass we already need to do it at least in `run_end_load` since it's one of the tests (the 1005 OnChanged notification). The reason is that it's called by gecko callback (via AddScriptRunner) and not from our msg loop.
We probably want to treat script runner like the other task processing, which would mean blocking task processing from `IRunnable::Run` or something like that.