Re: [TCLCORE] To the best of my recollection regarding TIP#302

[Dipl. I. S. G. B. <se...@us...>]

 

Sure, if one'd consider it as a pure enhancement...
I see it rather as a bug-fix (and an additional `after at` just to give
the user the possibility to handle, if the bug-fix would affect his
"cron" similar timers and they must match the wall clock as closely as
possible.

As already said, the factors of deviations are not comparable at all
(the mentioned 300000% and 0.03%). 

For instance, remaining by Donals example with hibernation (but also
another scenarios like suspending or pausing of VM, e. g. to temporary
free resources for some other tasks, to create offline-snapshot, to move
VM to other host, etc) - even the forward jumps may be an issue. So an
example code like this: 

 set timeout_ev [after 10000 { set ::state "TIMEOUT" }]
# do some very short async work (and timeout in 10 secs as very
unexpected): 
vwait ::state 
IF { $::state eq "TIMEOUT" } { error "BOOM: timeout occurred" } 
after cancel $timeout_ev 

or simplified variant like this (implementation of my RFE): 

 # do some very short async work (and timeout in 10 secs as very
unexpected): 
IF { [vwait 10000 ::state] } { error "BOOM: timeout occurred" } 

WOULD ALMOST ALWAYS FAIL with the timeout on such suspended
interruptions, IF THEY ARE USING WALL- INSTEAD OF MONOTONIC TIMERS and
the time gets synchronized immediately by resume (although otherwise the
issue becomes simply delayed).
While vice versa, with mono-clock (as implemented in my RFE), they would
run as expected, however the "opposite" timers (like cron-similar events
expecting wall-near time) could be executed just a bit later, but in
case of hibernation or long pause, it is anyway unclear (e. g. if the
end of the hibernation phase gets longer than the time of trigger, and
the VM would be resumed later it'd happen in any case delayed)... 
Anyway the injury potential is not comparable at all. I think it is
obvious to everyone, isn't it? 

Regards,
Sergey. 

06.05.2025 20:34, Kevin Kenny wrote: 

> On Tue, May 6, 2025 at 2:25 PM Dipl. Ing. Sergey G. Brester via Tcl-Core <tcl...@li...> wrote: 
> 
>> But, especially following your arguments, one can then say - lets switch `after` to mono-time by default (and provide `after -at` or `after -wall` or whatever for wall time)... Just because related to your assumptions, it wouldn't affect anything anyway (because "no long way jumps" is equal to "mono-time runs almost synchronous with wall-time").
> 
> My inclination is 'let's reserve script-breaking changes for major releases, preparing them with 'retroforward compatibility'. On the other hand, let's not go a quarter-century between major releases ever again. I don't know how we wound up trapped in that mind set; it was toxic. -- 
> 
> 73 de ke9tv/2, Kevin