Tcl - After problem under Windows

Author

After problem under Windows

informatique@jrtinc.com

2005-10-21, 7:57 am

Hello

When Windows ajusts the "Daylight Saving Time" back to normal (Normal
Eastern Time), all the "after" commands that are pending are delayed of
one hour. In my script, all the loops that are scheduled to run after a
few seconds won't run until an hour!

I did found on google a suggestion to use a proc that loops on itself,
and whose role is to detect changes in time setting and then delete and
restart all the affected "after" commands. But after some tests, we
found that it doesn't work all the time when many after commands of
little value (<50ms) are pending.

Do someone know a way to circumvent that problem.
Is this happening also under Unix/Linux or is it just another Windows
bug?
Is there a extension package out there that offer an "after" command
that do not rely on the time of the OS system, but instead on the
processor's clock tick.

Jean-Pierre

Robert Hicks

2005-10-22, 6:58 pm

This may not help but you can use "clock clicks ?-option?" and that
uses the cpu making it system independent. Maybe you can use that in
some way?

Robert

Robert Hicks

2005-10-22, 6:58 pm

This was an example of using "after" with "clock" from this group:

proc clock:set var {
global $var
set $var [clock format [clock seconds] -format %H:%M:%S]
after 800 [list clock:set $var]
}

Depending on how fine grained you want you just change [clock seconds]
to [clock ticks]...

Remember...I really have no clue what I am talking about. I am just
throwing you ideas.

Robert

Robert Hicks

2005-10-22, 6:58 pm

I ment [clock clicks]...or course. Um hmmm.

Mark Hobley

2005-10-22, 6:58 pm

Robert Hicks <sigzero@gmail.com> wrote:
> This may not help but you can use "clock clicks ?-option?" and that
> uses the cpu making it system independent. Maybe you can use that in
> some way?
>

Possibly use the above to check if the time has gone backwards, and if so,
invoke the missing tasks.

I recommend keeping the hardware clock at GMT, and just altering the displayed
time to your timezone. This way you never have the clock going backwards
problem, even though the displayed time suddenly jumps back an hour.

Regards,

Mark.

--
Mark Hobley
393 Quinton Road West
QUINTON
Birmingham
B32 1QE

Telephone: (0121) 247 1596
International: 0044 121 247 1596

Email: markhobley at hotpop dot donottypethisbit com

http://markhobley.yi.org/

Kevin Kenny

2005-10-30, 7:00 pm

informatique@jrtinc.com wrote:
> When Windows ajusts the "Daylight Saving Time" back to normal (Normal
> Eastern Time), all the "after" commands that are pending are delayed of
> one hour. In my script, all the loops that are scheduled to run after a
> few seconds won't run until an hour!

> Is this happening also under Unix/Linux or is it just another Windows
> bug?

I have seen the problem before; and only, ever, on Windows.
It's a bug in the Microsoft Visual C++ runtime library, and
I've been aware of it for about ten years. But Microsoft has
only recently acknowledged its existence:

http://support.microsoft.com/defaul...kb;en-us;821231

and provides no workaround.

Microsoft's own task scheduler has the same problems:

http://support.microsoft.com/defaul...kb;en-us;325413

This sort of problem has a long and lurid history, with Microsoft moving
the bugs around with every service pack. There simply does not appear
to be a reliable time reference to use across the transition. Even
setting the system to run in UTC doesn't always help. There have been
a number of bugs where Windows screws up timing at the US Daylight
Saving Time transitions even in a locale with non-US rules.

Part of the problem appears to be that Windows sets the hardware clock
to local time, rather than UTC, for the benefit of legacy DOS
applications. It then pulls the rug out from under itself at the
transitions.

All of the timing API's (WaitForMultipleEvents(), select(),
multimedia timers, ...) seem to share various versions of these bugs.
Believe me, I've tried. At NBC, I resorted to putting a SMPTE time
code reader on every PC in the control room, and driving the system
with interrupts from that. (But I recognize that most installations
don't have SMPTE time code wired throughout the plant, so that's
not a very portable solution...)

--
73 de ke9tv/2, Kevin

Jean-Pierre Tanguay

2005-10-31, 7:02 pm

Thank you Kevin for the explanation.

Jean-Pierre

Kevin Kenny a écrit :

> informatique@jrtinc.com wrote:
>
>
> I have seen the problem before; and only, ever, on Windows.
> It's a bug in the Microsoft Visual C++ runtime library, and
> I've been aware of it for about ten years. But Microsoft has
> only recently acknowledged its existence:
>
> http://support.microsoft.com/defaul...kb;en-us;821231
>
> and provides no workaround.
>
> Microsoft's own task scheduler has the same problems:
>
> http://support.microsoft.com/defaul...kb;en-us;325413
>
> This sort of problem has a long and lurid history, with Microsoft moving
> the bugs around with every service pack. There simply does not appear
> to be a reliable time reference to use across the transition. Even
> setting the system to run in UTC doesn't always help. There have been
> a number of bugs where Windows screws up timing at the US Daylight
> Saving Time transitions even in a locale with non-US rules.
>
> Part of the problem appears to be that Windows sets the hardware clock
> to local time, rather than UTC, for the benefit of legacy DOS
> applications. It then pulls the rug out from under itself at the
> transitions.
>
> All of the timing API's (WaitForMultipleEvents(), select(),
> multimedia timers, ...) seem to share various versions of these bugs.
> Believe me, I've tried. At NBC, I resorted to putting a SMPTE time
> code reader on every PC in the control room, and driving the system
> with interrupts from that. (But I recognize that most installations
> don't have SMPTE time code wired throughout the plant, so that's
> not a very portable solution...)
>
> --
> 73 de ke9tv/2, Kevin

Sponsored Links