What’s the point of the various …WhenCallbackReturns functions?

The thread pool provides a number of functions named ...When­Callback­Returns. What's the point of all these functions? Why can't you just do the operation yourself immediately before returning?

We saw Free­Library­When­Callback­Returns last time. What's the point of the others?

Basically, the same thing as Free­Library­When­Callback­Returns. It's a way to release a resource after execution has left the function and the callback is marked as complete. In the case of a synchronization resource, that resource may be what's keeping somebody from unloading your DLL, or it might protect a race condition between the callback function and a function that tries to cancel the callback.

Comments (6)
  1. So, from what I see here, the way Windows API treats its handles is the way a trigger-happy person fires a gun: He or she fires, regardless of the identity of the target: Foe, friendly or self. Thus, an additional function is put there to do the trigger-happy shooting and getting shot.

    Why can't it just verify target ID before trying to kill it?

  2. Ben Voigt says:

    It does verify the target ID.  The handle is the ID.

    For kernel handles, there is no race condition, because the handle can't be reused until you release your reference.  USER and GDI handles are more problematic, because non-owners using the handle have no way to prevent reuse.  Trouble arises, of course, when external code acts on these handles in a way that the code which owns them did not anticipate or permit.  But if you don't have permission to dig into resources of another component, it's really not surprising if things go awry.  And if you do have permission, then you can coordinate with the owning code to control the lifetime.

    Note that steps to correct this have already been taken.  USER and GDI have been replaced by a "Modern" API that is object-oriented and reference counted, so your concept of identity doesn't disappear if someone else closes the resource (you're left with a valid handle to a closed resource).  Unfortunately there's no equivalent for desktop apps… it isn't clear to me whether it would be possible to make one, but I think so.  There could be reference counted objects with one reference on behalf of (the user + all apps using the legacy handle) and that would disappear with DestroyWindow (for HWND) or DeleteObject (for GDI handles).  But the underlying object would still exist, in a closed state, until all consumers of the new object API released their references.

  3. @Ben Voigt:

    "The handle is the ID". Actually, it is the person that gets killed. It's like giving the picture of person to a hitman to kill. Now, sometimes, C++ programs give the picture of themselves. So, they use FreeLibraryAndExitThread to give the picture, so that the mistake would be FreeLibraryAndExitThread giving a picture of itself and getting killed.

    "USER and GDI have been replaced". Nice, unless of course, you mean .NET Framework, which technically does not replace them. But can I have the name of this modern API, please? Or, of course, an MSDN link would be much better.

  4. smf says:

    @Fleet Command

    It's more like an undertaker making arrangements for their own funeral with another undertaker.

  5. Crescens2k says:

    @Fleet Command:

    Object oriented and no equivalent for desktop apps means the Windows 8 UI applications, or Windows Store applications is what I would guess at.

  6. Oh! I see! Ben Voigt was referring to "Windows Runtime"! I guess I got excited for nothing…

Comments are closed.

Skip to main content