On Wed Nov 30 15:37:41 2022 +0000, Ivo Ivanov wrote:
If callbacks are pending at this point, then they've been triggered
and are just waiting for thread space to be executed. The purpose of the call here is exactly that - to cancel any pending callbacks that are about to be executed.
On the other hand, this isn't going to stop callbacks that are already
in process. Yes. According to the MS documentation for SetThreadpoolTimer(): _"In some cases, callback functions might run after an application closes the threadpool timer."_ (Remarks section) https://learn.microsoft.com/en-us/windows/win32/api/threadpoolapiset/nf-thre... Although they seem to imply that this includes also the queued callbacks, not just those in the execute phase: (pftDueTime parameter) _"If this parameter is NULL, the timer object will cease to queue new callbacks (but callbacks already queued will still occur)."_ And also in the Remarks section of CloseThreadpoolTimer(): _"The timer object is freed immediately if there are no outstanding callbacks; otherwise, the timer object is freed asynchronously after the outstanding callback functions complete."_ https://learn.microsoft.com/en-us/windows/win32/api/threadpoolapiset/nf-thre... Since the tp_object_cancel() removes pending callbacks, it can probably be removed. It won't make much of a difference though, and I think it makes more sense to cancel the pending callbacks there.
What I'm trying to say is I don't see why cancelling pending callbacks is going to *help* anything. In general I can see two reasons, in a situation like this, to cancel or flush some queued event:
* in order to avoid letting that event execute after the cancel
* in order to prevent anything from taking extra time waiting for those queued events to be processed
Neither of these seem to apply here. The former can't apply because the race is still present, as has been described. The latter doesn't seem like it should apply either, since there's nothing actually waiting for those callbacks to execute.