delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1998/06/18/07:56:37

From: kh AT wg DOT icl DOT co DOT uk (Kevin Hughes)
Subject: setittimer - bug found (I think)
18 Jun 1998 07:56:37 -0700 :
Message-ID: <01BD9AA1.18EC1860.kh.cygnus.gnu-win32@wg.icl.co.uk>
Reply-To: "kh AT wg DOT icl DOT co DOT uk" <kh AT wg DOT icl DOT co DOT uk>
To: "Gnuwin95 (E-mail)" <gnu-win32 AT cygnus DOT com>

Dear all,
	I reported odd behavior with the setittimer function recently - basically the available CPU gets
limited the more frequent the timer - and the "lost" time goes to system idle. I also noticed that the memory
being used increases slowly. The worst case I provoked was to setitimer to 5 millisec interrupt. I got NO
mill to my otherwise mill bound program and the system ran 98% idle (checked with Task manager
and perf monitor)

Having studied the code I think I know what is wrong.

	setittimer is implemented using SetTimer. When setittimer is called a call is made to SetTimer
with the appropriate value in the time out. When this occurs a WM_TIMER event occurs and is handled in 
a hidden window. This raises a SIGALRM. The trouble is it also re-evaluates the interval time and
starts another timer. Since SetTimer is not a single event but a repeated event we get a proliferation
of timers AND WM_TIMER events.

The failing code in window.cc, it looks really easy to fix - simply remove the start of a new timer in
the WM_TIMER case in the WndProc function. I would like to try this myself but as yet cannot rebuild
from the source.

A

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019