mirror of
https://github.com/reactos/reactos.git
synced 2024-12-29 10:35:28 +00:00
add comment about KeCancelTimer pitfall
svn path=/trunk/; revision=18419
This commit is contained in:
parent
697b562c6b
commit
29b7b9b24a
1 changed files with 13 additions and 0 deletions
|
@ -34,6 +34,19 @@ VOID STDCALL KiHandleExpiredTimer(PKTIMER Timer);
|
||||||
* Timer = timer to cancel
|
* Timer = timer to cancel
|
||||||
* RETURNS: True if the timer was running
|
* RETURNS: True if the timer was running
|
||||||
* False otherwise
|
* False otherwise
|
||||||
|
*
|
||||||
|
* DANGER!
|
||||||
|
* The statement in the DDK for KeCancelTimer that "if a DPC object is
|
||||||
|
* associated with the timer, it too is canceled" is wrong -- nothing is
|
||||||
|
* done with the DPC object when the timer is removed from the system
|
||||||
|
* queue. So its very likely that the DPC will run after you have canceled
|
||||||
|
* the timer!
|
||||||
|
* For what it's worth, calling KeRemoveQueueDpc after KeCancelTimer would
|
||||||
|
* be sufficient to prevent any problems associated with destroying the DPC
|
||||||
|
* object, at least as the OS is currently implemented. This is because the
|
||||||
|
* DPC dispatcher doesn't need access to the object once the DPC is
|
||||||
|
* dequeued, and the dequeuing happens before the DPC routine gets called."
|
||||||
|
* -Gunnar (article by Walter Oney)
|
||||||
*/
|
*/
|
||||||
BOOLEAN
|
BOOLEAN
|
||||||
STDCALL
|
STDCALL
|
||||||
|
|
Loading…
Reference in a new issue