Skip to content

Conversation

@oldnewthing
Copy link
Member

Fortunately, the Ex versions behave the same as the Win7 versions, so we can just switch everybody to the Win7 versions.

Fixes #894

Fortunately, the Ex versions behave the same as the Win7
versions, so we can just switch everybody to the Win7 versions.
@oldnewthing oldnewthing requested a review from kennykerr March 20, 2021 16:40
Copy link
Collaborator

@kennykerr kennykerr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sweet!

@kennykerr kennykerr merged commit 1502e29 into master Mar 22, 2021
@kennykerr kennykerr deleted the win7 branch March 22, 2021 13:04
void fire_immediately() noexcept
{
if (WINRT_IMPL_SetThreadpoolTimerEx(m_timer.get(), nullptr, 0, 0))
if (WINRT_IMPL_SetThreadpoolTimer(m_timer.get(), nullptr, 0, 0))
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to SetThreadpoolTimer docs, it returns void instead of BOOL, is it OK to use this return value?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well spotted - @oldnewthing I'm guessing this means we don't have test coverage for this one. 😟

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strange, because there's a cancellation test. Will have to figure out how this slipped through. Probably because I messed up.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, the deal is that this works on Win8+ due to how SetThreadpoolTimer is implemented (it calls SetThreadpoolTimerEx and throws away the result, but the result is still lying around in eax so we can still act on it). But this won't work on Win7, where eax does not contain anything meaningful. It looks like timer cancellation propagation will not work on Win7. Should I do GetProcAddress/dynamic light-up?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we'll have to do that. You can (almost) use load_runtime_function except that its currently only used for combase functions and the thread pool is implemented by kernel32.

template <typename F, typename L>
void load_runtime_function(char const* name, F& result, L fallback) noexcept
{
if (result)
{
return;
}
result = reinterpret_cast<F>(WINRT_IMPL_GetProcAddress(WINRT_IMPL_LoadLibraryW(L"combase.dll"), name));
if (result)
{
return;
}
result = fallback;
}

This is the way Win7 fallback is handled, for example:

inline int32_t __stdcall fallback_RoGetActivationFactory(void*, guid const&, void** factory) noexcept
{
*factory = nullptr;
return error_class_not_available;
}
template <bool isSameInterfaceAsIActivationFactory>
WINRT_IMPL_NOINLINE hresult get_runtime_activation_factory_impl(param::hstring const& name, winrt::guid const& guid, void** result) noexcept
{
if (winrt_activation_handler)
{
return winrt_activation_handler(*(void**)(&name), guid, result);
}
static int32_t(__stdcall * handler)(void* classId, winrt::guid const& iid, void** factory) noexcept;
impl::load_runtime_function("RoGetActivationFactory", handler, fallback_RoGetActivationFactory);
hresult hr = handler(*(void**)(&name), guid, result);

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't quite do it that way because I want to disable a feature if the GetProcAddress fails. There is no "fallback" available. (I guess I could see if result == fallback_Blah.)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whatever you think is best.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SetThreadpoolWaitEx and SetThreadpoolTimerEx are not available in Windows 7

4 participants