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

[Kevin K. <kev...@gm...>]

I'm willing to concede the point if the consensus runs against me, because
to me it's a close call.  It does, as I mentioned, fall in my mental
category of 'script-breaking changes that, if implemented, would probably
fix more bugs than they introduce.'

On Wed, May 7, 2025 at 9:51 AM Dipl. Ing. Sergey G. Brester <
se...@us...> wrote:

> 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
>
>

-- 
73 de ke9tv/2, Kevin