From: Dipl. I. S. G. B. <se...@us...> - 2025-05-05 20:53:35
|
Just to point to existing implementation of monotonic and after at - [fdfbd5e10] [2]. In my own fork it works (in production) in more or less exact this form longer than 10 years without any issues (and after the switch of almost all timers and timeouts to monotonic time without "unexplainable" large "hangs", in case of backwards time jumps or adjustments). Regarding the Christians points, mostly agree with almost everything (excepting removal of virtual time). Regarding the slave interp (and other timeouts and time-based handlers), - yes - they shall be surely monotonic (otherwise sporadic "unexplainable" large hangs remain unavoidable). Regarding the resolution: - my implementation accepts double by timers (e. g. `after 0.01` - sleep for 10 microseconds); - one could introduce new additional option e. g. -seconds, -micro, -milli to adjust the base; Regards, Sergey 05.05.2025 20:45, Christian Werner wrote: > Hello all, > > some points to discuss: > > * the clock domain should be switched from wall clock to a monotonic clock source in POSIX speak > * this should ideally not have an impact on time computations in Tcl core > * however, POSIX monotonic clock must be used in both clock_gettime() and condition variables > * maybe it's a good idea to detect availability of monotonic clock and fall back to wall clock if not available > * the time bound on slave interp evaluations is unfortunately in wall time which is IMO a failure in design > * what about virtual time, can this be ditched entirely, there ain't no test cases and no examples > * the "after -at" form is a special case to allow for cron like requirements, is this ever a use case? > * what is the resolution of "after -at", when it's like cron one second seems enough > * for symmetry another "after -mono" can be imagined which is like "after -at" but in the monotonic clock domain > * the resolution of "after -mono" should be near the tick rates of contemporary OSes (e.g. milliseconds) > > Best regards, > Christian > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core [1] Links: ------ [1] https://lists.sourceforge.net/lists/listinfo/tcl-core [2] https://core.tcl-lang.org/tcl/tktview/fdfbd5e10 |