Question about TIP#302

[yyamasak]

Is there any possibility that TIP#302 could be implemented in the near future?
It has been at Draft state for 10 years.
But it has Tcl-Version: 8.7 in its header, so I had a small hope that someone is thinking of it.

For the time being, I avoid this problem by the frequent NTP polling interval on Windows (against private NTP server.)

[Harald Oehlmann]

Hi !

Thank you for asking. This is a typical message for the tcl-core mailing
list.

IMHO the delay has little to do with the targeting field, but of the
lack of:
- interested people
- implementation
- discussion

I suggest to write a suitable mail to tcl-core and to write your opinion
on the options given in the TIP.

-Harald

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Gerald W. Lester]

On 3/22/16 12:07 PM, Harald Oehlmann wrote:
> Am 22.03.2016 um 16:09 schrieb yyamasak:
>> Is there any possibility that TIP#302 could be implemented in the near future?
>> It has been at Draft state for 10 years.
>> But it has Tcl-Version: 8.7 in its header, so I had a small hope that someone is thinking of it.
>>
>> For the time being, I avoid this problem by the frequent NTP polling interval on Windows (against private NTP server.)
>>
> Hi !
>
> Thank you for asking. This is a typical message for the tcl-core mailing
> list.
>
> IMHO the delay has little to do with the targeting field, but of the
> lack of:
> - interested people
> - implementation
> - discussion
>
> I suggest to write a suitable mail to tcl-core and to write your opinion
> on the options given in the TIP.

Even better, write a sample implementation.

[yyamasak]

Hello Harald and Gerald,

I am a mere Tcl script writer.
But I will try to write a reference implementation when I have time.

I'm thinking of combining the following implementations.

https://groups.google.com/d/msg/comp.lang.tcl/j4IMaBQ4UPk/1jCNX485H4gJ
https://github.com/awreece/monotonic_timer/blob/master/monotonic_timer.c

Here are the previous discussions about this issue.

https://sourceforge.net/p/tcl/bugs/3410/
https://groups.google.com/d/msg/comp.lang.tcl/1Aap4TnJ7ng/pPmYVChAMVMJ
https://groups.google.com/d/msg/comp.lang.tcl/j4IMaBQ4UPk/1jCNX485H4gJ
http://www.devsuperpage.com/search/Articles.aspx?G=7&ArtID=591888
http://fossil.etoyoc.com/sandbox/tcl/tktview/3328635fffffffffffffffffffffffffffffffff?plaintext

[Harald Oehlmann]

Great,
all this valuable info should go into a ticket on core.tcl.tk/tcl
, or at least on the wiki.

Thanks,

[Donal K. Fellows]

On 23/03/2016 06:17, yyamasak wrote:
> I am a mere Tcl script writer.

There's nothing wrong with that. It's an accepted route to start with
everything (or nearly everything) in Tcl and then to progress to having
more bits in C as required. Sometimes it isn't required at all.

> But I will try to write a reference implementation when I have time.

I think the main thing will be to identify a way of spotting that a
clock change occurred, and figuring out how to update the deadlines in
the queue of timer events when that happens. Which might mean re-sorting
them. Or perhaps maintaining two separate queues.

You ought to get in contact with the TIP's authors.

Process-wise, the TIP is waiting for an implementation. After a few bad
experiences with stuff getting voted for and never implemented, we'll
delay on the vote until we see evidence that the feature is practical.
It doesn't have to be the *final* version, but it does have to be an
initial version.

Donal (I just NTP-synch all my machines... :-))
--
Donal Fellows — Tcl user, Tcl maintainer, TIP editor.

[pal...@yahoo.com]

While you wait for the TIP :-), IF you are on Windows AND you don't mind using twapi, the following set of procedures might help (assuming the Windows WaitFor* API uses the tick count and not date/time setting which I suspect is the case).

package require twapi

proc _timer_handler {only_once script hevent sig} {
if {$only_once} {
cancel $hevent
}
uplevel #0 $script
}

proc delay {ms script} {
set hevent [twapi::create_event]
twapi::wait_on_handle $hevent -wait $ms -async [list _timer_handler 1 $script]
return
}

proc every {ms script} {
set hevent [twapi::create_event]
twapi::wait_on_handle $hevent -wait $ms -async [list _timer_handler 0 $script]
return $hevent
}

proc cancel {hevent} {
catch {twapi::cancel_wait_on_handle $hevent}
twapi::close_handle $hevent
}

delay runs the script once. every runs continuously and has to be canceled with cancel.

% delay 1000 "puts dingdong"
dingdong
% set id [every 1000 "puts dingdong"]
580 HANDLE
dingdong
dingdong
dingdong
dingdong
% cancel $id

Note the event loop must be running.

For demo purposes only, needs to be made robust

/Ashok

[Alexandre Ferrieux]

On Wednesday, March 23, 2016 at 12:37:03 PM UTC+1, Donal K. Fellows wrote:
>
> I think the main thing will be to identify a way of spotting that a
> clock change occurred, and figuring out how to update the deadlines in
> the queue of timer events when that happens. Which might mean re-sorting
> them. Or perhaps maintaining two separate queues.

Personally I don't like "detect-and-fix" approaches because unless you have completely instantaneous detection and atomic fix, race conditions are bound to happen, and you'll end up with the very same symptoms (an [after] that blocks for ages).

As outlined in the TIP, the value returned by times() in Unix and GetTickCount() in Windows happens to be a clean and monotonic timebase.
Unfortunately, times() only has a centisecond resolution on Linux, unfit for our millisecond-based timers. Nowadays clock_gettime(CLOCK_MONOTONIC) is widely implemented and might replace it.

> Donal (I just NTP-synch all my machines... :-))

Yeah, but in some cases that's not an option: either the machine is too isolated, or you prefer a drifting but consistent local hardware timebase over an inconsistent one that gets skewed from time to time by ntpd's adjustment, as delicate as they try to be...

-Alex

[Yusuke Yamasaki]

Hello Ashok,

My main platform is Windows and I can't live without twapi anymore.
I know a program written in C++ using WaitFor*, SetEvent and Sleep in threads for timers. It is not affected by the change of system clock.

My issue will be solved by replacing afters by your delay command (with some modification to the arguments.)

Thank you for the good example...so good that I think I can't keep motivation about TIP#302 in spite of Donal's encouragement...

/Yusuke

[Donal K. Fellows]

On 23/03/2016 23:07, Alexandre Ferrieux wrote:
> Yeah, but in some cases that's not an option: either the machine is
> too isolated, or you prefer a drifting but consistent local hardware
> timebase over an inconsistent one that gets skewed from time to time
> by ntpd's adjustment, as delicate as they try to be...

My stuff is pretty solidly network-dependent anyway and sitting on a
gigabit network, so syncing with NTP even as often once a minute is no
big deal. If the hardware drifts fast enough that that's too often, I
get different hardware that isn't broken.

Different environment. :-D

Donal.

[Donald Arseneau]

I thought this was already patched?!?! I swear I recently saw changes (which may not be recent)
to use clock_gettime( CLOCK_MONOTONIC ) on Linux and something different on Windows.


--
Donald Arseneau as...@triumf.ca

[Yusuke Yamasaki]

Hello Donald,

At least Tcl/Tk 8.5.18 for Windows doesn't have a patch.
I tried Ashok's workaround but it seemed it doesn't go well with Tcl event loop.
It might be because my code, Tk's dialogs and some tklib packages depend on "after idle" and "update ?idletasks?" and these can't be replaced by twapi::wait_on_handle.

https://gist.github.com/yyamasak/a360ae573025016fe3e06e706ffe5066

Regards,
Yusuke

[undro...@gmail.com]

Yusuke-san,

there's a draft implementation for Win32 and POSIX in a branch of the Tcl core, see the comment section in

http://core.tcl.tk/tcl/timeline?n=100&r=tip-302

Best,
Christian

[Yusuke Yamasaki]

Hello Christian-san,

That's great!
I wish it could be back-ported to 8.5.20 too.

Regards,
Yusuke

[undro...@gmail.com]

Yusuke-san,

meanwhile the patch evolved somewhat as you can read in

http://core.tcl.tk/tcl/tktview/3328635fffffffff

There are now two patches for core-8-6-branch and core-8-5-branch
and a 8.6 branch with the patch applied in the fossil tag
"tkt3328635-posix-monotonic-clock". Hope, that you can rebuild
8.5 and check out the patch.

Best,
Christian

[Yusuke Yamasaki]

Hello Cristian-san,

Thank you for your information. I tried WIN32_USE_TICKCOUNT.
While running a timer script, I changed the Windows system clock back and forth.
The interval was constant as expected. Great!

----------------
(MinGW)
wget --no-check-certificate https://core.tcl.tk/tcl/zip/Tcl+Source+Code-965d56c3af.zip?uuid=965d56c3aff59613
./configure --prefix=/c/bin/tcl8.7a0 CFLAGS="-DWIN32_USE_TICKCOUNT"
make install

----------------
C:\bin\tcl8.7a0\bin>type check_timer.tcl
proc start_timer {} {
global tm_last
set tm_last [clock seconds]
tick
}

proc stop_timer {} {
after cancel tick
}

proc tick {} {
global interval tm_last
set tm_now [clock seconds]
set tm_now_s [clock format $tm_now]
set elapse(sec) [expr {$tm_now - $tm_last}]
puts "\[$tm_now_s\] tick elapse(sec)=$elapse(sec)"
set tm_last $tm_now
after $interval tick
}

set interval 3000
start_timer

vwait forever

C:\bin\tcl8.7a0\bin>tclsh87.exe check_timer.tcl
[Thu Sep 29 10:07:36 JST 2016] tick elapse(sec)=0
[Thu Sep 29 10:07:39 JST 2016] tick elapse(sec)=3
[Thu Sep 29 10:07:42 JST 2016] tick elapse(sec)=3
[Thu Sep 29 10:07:45 JST 2016] tick elapse(sec)=3
[Thu Sep 29 10:07:48 JST 2016] tick elapse(sec)=3
[Wed Sep 28 10:07:50 JST 2016] tick elapse(sec)=-86398
[Wed Sep 28 10:07:53 JST 2016] tick elapse(sec)=3
[Wed Sep 28 10:07:56 JST 2016] tick elapse(sec)=3
[Wed Sep 28 10:07:59 JST 2016] tick elapse(sec)=3
[Wed Sep 28 10:08:02 JST 2016] tick elapse(sec)=3
[Wed Sep 28 10:08:05 JST 2016] tick elapse(sec)=3
[Wed Sep 28 10:08:08 JST 2016] tick elapse(sec)=3
[Wed Sep 28 10:08:11 JST 2016] tick elapse(sec)=3
[Wed Sep 28 10:08:14 JST 2016] tick elapse(sec)=3
[Wed Sep 28 10:08:17 JST 2016] tick elapse(sec)=3
[Thu Sep 29 10:08:19 JST 2016] tick elapse(sec)=86402
[Thu Sep 29 10:08:22 JST 2016] tick elapse(sec)=3
[Thu Sep 29 10:08:25 JST 2016] tick elapse(sec)=3
[Wed Sep 28 10:08:27 JST 2016] tick elapse(sec)=-86398
[Wed Sep 28 10:08:30 JST 2016] tick elapse(sec)=3
[Wed Sep 28 10:08:33 JST 2016] tick elapse(sec)=3
[Wed Sep 28 10:08:36 JST 2016] tick elapse(sec)=3
[Wed Sep 28 10:08:40 JST 2016] tick elapse(sec)=4
[Thu Sep 29 10:08:42 JST 2016] tick elapse(sec)=86402
[Thu Sep 29 10:08:45 JST 2016] tick elapse(sec)=3
[Thu Sep 29 10:08:48 JST 2016] tick elapse(sec)=3
----------------


Regards,
Yusuke

[Yusuke Yamasaki]

Hello Christian-san,

I wish WIN32_USE_TICKCOUNT to be the default option for Windows build because I prefer ActiveTcl binary which will be compiled using the default options.

Regards,
Yusuke