add comment about KeCancelTimer pitfall
Modified: trunk/reactos/ntoskrnl/ke/timer.c

Modified: trunk/reactos/ntoskrnl/ke/timer.c
--- trunk/reactos/ntoskrnl/ke/timer.c	2005-10-12 22:15:22 UTC (rev 18418)
+++ trunk/reactos/ntoskrnl/ke/timer.c	2005-10-12 23:10:31 UTC (rev 18419)
@@ -34,6 +34,19 @@
  *       Timer = timer to cancel
  * RETURNS: True if the timer was running
  *          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
 STDCALL