Tcl Source Code

Hi,

I have a several Labels which were filled by a socket 
communication with a console program 10 times per 
second. This works fine with about 1%-2% cpu-
performance.

i also have another program which does a while-loop and 
in this while loop it makes a sleep of one ms. For this i 
used before the while loop the command timebeginperiod
(1). This allows timing accurracy of one millisecond. If 
this program runs standalone it also uses 1%-2% 
performance.

Now the problem :
If both programs are run the cpu-performance increases 
to about 20%-50%. Tested on NT/2000, slow and fast 
cpu. Wish is now on topmost of process list !
I also tried it in debug -modus and exactly after i do the 
command timebeginperiod(1) the cpu-usage increases !

There must be a bug in the timing-routine of tcl !

Example programs appended.
1.) first start tcl-script then showmess. Look for CPU-
usage
2.) close both and start checkmittimebegin1. Look for 
cpu-usage
3.) start all three and look for cpu-usage

Thanks in advance
Joe
[email protected]

Logged In: YES 
user_id=99768

This problem is not quite a bug.

On Windows, as indeed on most systems, when a thread asks to
delay
for a given time, the time is rounded to a "clock tick" - one
cycle of some external oscillator.  On the various versions of
Windows, the size of a clock tick varies; it may be as long as
60 ms or as short as a millisecond.

The [after] command attempts to hide this granularity.  When the
wait time is shorter than a clock tick, the kernel call that
it uses
actually makes the thread wait for zero time, and become
immediately
available for redispatch.  At that point, the Tcl notifier
checks
whether any timer events are ready for service, finds that none
is (because the necessary millisecond has not yet elapsed), and
again delays for zero time.  This zero delay causes a behavior 
in which the notifier is using apparently all the CPU.

If any other thread is contending for the CPU, however, it will
get its full time quantum when it comes to the head of the
queue.
At that point, the notifier thread will use a short burst of CPU
checking for events, relinquish the processor, and allow the
CPU-intensive thread to proceed once again.  As far as I can
tell,
while it appears alarming, the CPU usage when short [after]
events
are scheduled is simply CPU time that is transferred from the
idle loop.

If you've actually observed system performance being adversely
affected, rather than simply an alarming number on the Task
Manager,
please reopen this issue and we'll investigate further.  At the
present time, as far as we can tell, the fact that Tcl takes
over part of the system's idle time has not been observed to
have any significant impact.

Logged In: NO 

I used a pentium 450 MHz with 380 MB and had about 20% 
CPU-Usage with all programs running. And only 1 % if the 
programs run standalone.
On my notebook 2.2GHz the effect was also not shown but 
after i increased the messages to the TCL-display and made 
some more outputs it was the same effect.
THERE IS A DEPENDANCE BETWEEN TIMEBEGINPERIOD(1) AND 
TCL.
If someone wants the Test-Programs for higher CPU's please 
send me a mail because i don't know how to add these to the 
existing problem.

Thanks in advance
Joe
[email protected]

Logged In: YES 
user_id=1130415

On Windows XP Prof. (1 GHz, 512 MB Ram) under Tcl 8.4.5, I
wasn't able to reproduce the described problem. When I start
all three programs the way you describe, the CPU usage does
not go beyond 4%. The programs ARE certainly running,
according to the changing output in all three windows.

File Added - 103475: BugReport.zip