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

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

 

Comments inlined... 

06.05.2025 10:34, Harald Oehlmann wrote: 

> Christian, Sergey, thank you for your valuable contributions. We need that!
> It is an absolute requirement for an integration system to work. 
> 
> Yesterday, in the meeting, there was a strong objection to:
> - change current after in using the wall clock

And they are?
The thing is:

 	* one can consider the change of current `after` to monotonic time as
a bug-fix, because otherwise it can unexpectedly take too long by
possible time jumps backwards (or too short by forwards jumps), e. g.
abrupt the timer `after 100 ...` will be triggered in 1 hour instead of
few milliseconds. With other words it is not a feature (only), but
rather a bugfix in my opinion.
 	* mostly (probably 99%) `after` will be used for short intervals, so
the monotonic time is not only better suitable in this case, but
absolute necessary; In event-driven application it is mandatory to
handle any kind of timeout properly. For instance, before switch the
implementation to mono-base we observed sporadic large "hangs" of whole
system (distributed computing).

	* even for the case where `after` is used for long playing timers (like
cron tasks, etc), it is not a big issue, because in this case it'd be
only affected (and the difference becomes visible) by the time
adjustments, and by such long timers it is not so flashy as by the short
timers, because would only take a small fraction compared to whole
interval. 
Just compare:

		AFTER-BASE
		TIMER
		TIME JUMPS BACK FOR 5 MIN
		DEVIATION

 		wall clock
 		after 100ms (timeout)
 		execution delayed for 5 minutes
 		300000%

 		after 1day (cron-time)
 		execution happens as "expected"
 		-

 		monotonic
 		after 100ms (timeout)
 		execution happens as expected
 		-

 		after 1day (cron-time)
 		execution happens 5 minutes earlier
 		0.3%

 The issue is obvious, isn't it?
Let alone if the "expected" behaviour of cron-time really to be as
precise as possible (by wall time),
it could be relative fast rewritten using new handler (after -at or
whatever);
Sure not well backwards compatible, but considering the deviation factor
surely justified and only correct in this way. 	* the change of after is
not enough at all, to handle everything properly we need to replace
several timeouts with monotonic time (otherwise same issue as mentioned
above with the hangs are unavoidable and especially evil by locks, up to
absolute "no go" by conditional cross-process locks).

> - not use a command switch, but a new command for the new monolitic after, as this is seen as the future. 
> 
> The way is not so important. Important is to get it. But sematics is always good for discussions ;-).

Sure. However in my case it is important, since already used dozen
years.

But it is indeed a matter of discussion, however I am sure the
implementation of both (mono-time and `after -at`) needs to be done
simultaneously (and released together). 

> Christian, I am probably blind. Where is your "after -at" patch ?

> Sergey, would it possible to extract the monolitic clock part of your big code contributions ?

Well, it is a bit complex - some changes (timers rewrite, event
handling, etc) are strict necessary, another (vwait, options for
vwait/after for event masks, higher resolution, etc) are pure features
fewer related to the monotonic clock, but depend on it... 

We have already discussed the subject several times in tclchat. For
example with Kevin Kenny, and IIRC the last conclusion was:

- either to write several TIPs to discuss the RFE in parts (but let the
code as is and adjust it later if expected);
- or to split the code in few parts from scratch; 

Since the latter would also expect the same TIPs as in the former,
possibly the right way is to start with the former. 

Regards,
Serg. 

P.S. @Christian: your rude t-online provider rejected my mail on you
yesterday with following error:
554 IP=... - None/bad reputation. Ask your postmaster for help or to
contact to...@rx... for reset. (NOWL)
Just to inform you, that they censor the customer's emails without their
knowledge (I guess you were not notified about the mail or its reject).
That "none" lets assume that they reject any mail from relays without
reputation... I must admit, I never saw such a stupid block reason
before.