Re: [PATCH v8 0/3] MR4243: rtworkq: free cancelled work items

[Zhiyi Zhang (＠zhiyi)]

Zhiyi Zhang (@zhiyi) commented about dlls/mfplat/tests/mfplat.c:
>  ok(hr == S_OK, "Failed to cancel item, hr %#lx.\n", hr);
>
>  refcount = IMFAsyncCallback_Release(&callback->IMFAsyncCallback_iface);
> - todo_wine ok(refcount == 0, "Unexpected refcount %lu.\n", refcount);
> - ok(refcount == 0, "Unexpected refcount %lu.\n", refcount);

After 7865026, won't the callback be eventually released in scheduled_item_cancelable_callback() or waiting_item_cancelable_callback()? How does the memory leak happen? If you're referring to the callback reference count should immediately be zero after calling MFCancelWorkItem(), I don't think that's that big of an issue. Is there an application that depends on the reference count being zero immediately after MFCancelWorkItem()?