Prev: Creating a partition programmatically
Next: Service parameters ignored
From: josephm7 on 8 Dec 2009 06:47
I am supporting a system on Windows XP/2003 and we have come across a
situation where the documentation for DeleteTimerQueueTimer is inconsistent
with its behaviour. The code in use first creates a timer using
CreateTimerQueueTimer with a callback and the timer executing off the timer
thread

CreateTimerQueueTimer(
&mTimerHandle,
mTimerQueue,
&CTimer::TimerCallback,
(PVOID) this,
DueTime,
Period,
WT_EXECUTEINTIMERTHREAD );

We then may delete the timer at any stage using the folllowing code:
DeleteTimerQueueTimer( mTimerQueue, mTimerHandle, NULL );

What we have found is that if the callback above is already being called
when DeleteTimerQueueTimer is called, DeleteTimerQueueTimer will not return
until the callback is complete. This behaviour is inconsistent with what is
stated in MSDN for the third parameter in the DeleteTimerQueueTimer call
(CompletionEvent):

"If this parameter is NULL, the function marks the timer for deletion and
returns immediately. If the timer has already expired, the timer callback
function will run to completion. However, there is no notification sent when
the timer callback function has completed. Most callers should not use this
option, and should wait for the timer callback function to complete so they
can perform any needed cleanup."

We have since done some testing on Windows XP, Windows Server 2003, Windows
7 and Windows Server 2008. We have found that the function will block until
the callback returns for Windows XP and Windows Server 2003, but will return
immediately for Windows 7 and Windows Server 2008.

Does anybody know if there is a specific bug for this windows api call in
Windows XP and Windows Server 2003? I have a simple example I can send to
anyone that is interesting in helping.
 | 
Pages: 1
Prev: Creating a partition programmatically
Next: Service parameters ignored