The Windows thread pool lets you create, among other things, timers and waits, and you can cancel them, too.<\/p>\n
There are some finer points here.<\/p>\n
The way you cancel a timer is to call When you cancel a timer or wait, no future callbacks will be created, but existing ones are not recalled. Therefore, there’s a race condition if you issue you your cancellation just after the timer or wait has triggered: You cancelled it too late to prevent the callback from being scheduled, and you can’t detect this race from your callback because the callback may not have started running yet. This could be because the callback has been scheduled but hasn’t yet been given a thread to run on yet. Or it could be that your callback was unluckily pre-empted at its very first instruction.<\/p>\n A timer or wait is created in the “unset” state. You put into the “set” state by calling one of the When you call one of the Here’s a table of the possibilities:<\/p>\n The last row is the interesting one: When you cancel the timer or wait object, the thread pool tries to recall any pending callbacks, but sometimes a callback has already gone too far and could not be recalled. For example, the callback could be already in progress. In that case, the The way you wait for the callback to complete is to call Fortunately, the We can now put this information to use: Suppose you have a thread pool timer or wait that has been set, and you later realize that you don’t want to wait that long after all. What is the pattern for safely accelerating the callback?<\/p>\n If we assume that the timer or wait is definitely set, then the Unset<\/i> row is removed from consideration, and that means that a Otherwise, there was no callback in progress, so we need to make one. We can do that by resetting the timer or wait callback with a timeout of zero (which means now<\/i>).<\/p>\n In the case of making a wait callback run immediately, we have to give it a non-null handle, although we don’t care what it is. We use the pseudo-handle to the process itself, which the process will never observe as signaled. That way, the callback is made with the report that the wait timed out.<\/p>\n","protected":false},"excerpt":{"rendered":" Assorted little details.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-108110","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":" Assorted little details.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108110","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=108110"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108110\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=108110"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=108110"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=108110"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Set\u00adThreadpool\u00adTimer<\/code> or Set\u00adThreadpool\u00adTimer\u00adEx<\/code> with a null pointer as the due time. And the way you cancel a wait is to call Set\u00adThreadpool\u00adWait<\/code> or Set\u00adThreadpool\u00adWait\u00adEx<\/code> with a null handle.<\/p>\n\n\n
\n Thread pool<\/th>\n You<\/th>\n<\/tr>\n \n Object is signaled \/ timer is ready
\nCallback scheduled<\/td>\n <\/td>\n<\/tr>\n \n \u00a0<\/td>\n Cancel timer \/ wait<\/td>\n<\/tr>\n \n Thread assigned to callback
\nCallback runs<\/td>\n <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Set...<\/code> functions with a non-null due time or handle. You return it to the “unset” state by calling the the Set...<\/code> functions with a null due time or handle.<\/p>\nSet...Ex<\/code> functions, it returns a value that tells you whether a callback was cancelled. But that’s only part of what you need to know in order to determine whether a callback is on its way. You also need to know whether the timer or wait was previously set.<\/p>\n\n\n
\n Previous state<\/th>\n Was callback pending<\/th>\n Could callback be recalled<\/th>\n Set returns…<\/th>\n<\/tr>\n \n Unset<\/td>\n N\/A<\/td>\n N\/A<\/td>\n FALSE<\/code><\/td>\n<\/tr>\n\n Set<\/td>\n No<\/td>\n N\/A<\/td>\n TRUE<\/code><\/td>\n<\/tr>\n\n Set<\/td>\n Yes<\/td>\n Yes<\/td>\n TRUE<\/code><\/td>\n<\/tr>\n\n Set<\/td>\n Yes<\/td>\n No<\/td>\n FALSE<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nSet...Ex<\/code> function returns FALSE<\/code> to tell you that you’re not finished yet. You have to wait for the callback to complete before everything is finally done.<\/p>\nWait\u00adFor\u00adThreadpool\u00adTimer\u00adCallbacks<\/code> or Wait\u00adFor\u00adThreadpool\u00adWait\u00adCallbacks<\/code>. It will wait for the completion of all outstanding callbacks for the specified timer or wait. A callback is deemed to have completed when it returns, or when it calls Dissociate\u00adCurrent\u00adThread\u00adFrom\u00adCallback<\/code>. We can add this as another column to our table:<\/p>\n\n\n
\n Previous state<\/th>\n Was callback pending<\/th>\n Could callback be recalled<\/th>\n Set returns…<\/th>\n Wait returns…<\/th>\n<\/tr>\n \n Unset<\/td>\n N\/A<\/td>\n N\/A<\/td>\n FALSE<\/code><\/td>\nImmediately<\/td>\n<\/tr>\n \n Set<\/td>\n No<\/td>\n N\/A<\/td>\n TRUE<\/code><\/td>\nImmediately<\/td>\n<\/tr>\n \n Set<\/td>\n Yes<\/td>\n Yes<\/td>\n TRUE<\/code><\/td>\nImmediately<\/td>\n<\/tr>\n \n Set<\/td>\n Yes<\/td>\n No<\/td>\n FALSE<\/code><\/td>\nAfter callback completes<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Wait\u00adFor\u00ad...\u00adCallbacks<\/code> functions wait in exactly the case we need them to wait.<\/p>\nFALSE<\/code> return value from Set...Ex<\/code> tells us that a callback is in progress, or at least has proceeded past the point of no return. In that case, we don’t need to accelerate the callback; it’s already on its way.<\/p>\nif (SetThreadpoolTimerEx(timer, nullptr, 0, 0)) {\r\n FILETIME now = { 0, 0 };\r\n SetThreadpoolTimer(timer, &now, 0, 0);\r\n}\r\n\r\nif (SetThreadpoolWaitEx(wait, nullptr, nullptr, nullptr)) {\r\n FILETIME now = { 0, 0 };\r\n SetThreadpoolWait(wait, GetCurrentProcess(), &now);\r\n}\r\n<\/pre>\n