Make this_thread::sleep_until clock-aware

[achabense]

Partially addresses #718.

Fixes this_thread::sleep_until / sleep_for:

• replace _Thrd_sleep with _Thrd_sleep_for, which is a direct call to windows Sleep (_Thrd_sleep also relies on Sleep, but is bound to system-clock).
• replace usage of _To_timespec64_sys_10_day_clamped with clock-aware logic in sleep_until.

Thanks to @AlexGuteniev for helping me figure out how to add import-library functions ❤️

[AlexGuteniev]

There are still the following functions:

_CRTIMP2_PURE int __cdecl _Mtx_timedlock(_Mtx_t, const xtime*);
_CRTIMP2_PURE int __cdecl _Cnd_timedwait(_Cnd_t, _Mtx_t, const xtime*);

I think we should either not resolve the original issue or create a follow-up issue.

[BillyONeal]

I'm leaving these comments in my capacity as an individual; I'm no longer a maintainer and won't be following this PR going forward, but I think the folks who actually are maintainers should consider them. In particular, I feel strongly that ns is not the correct type when all platform APIs speak FILETIME 100ns units. (The other comments are really nitpicks)

[achabense]

In this pr, should I:

1. make _Thrd_sleep_for accept 100ns instead?
2. make _Reltime_ns_10_day_clamped more general?
   2.1. let this function take _Now and _Then as parameters, so that not to call _Clock::now() within the function? (Also have to decide whether to take _Now<(=)_Then as precondition)
   2.2. make clamp value a template parameter?
   2.3. make return type a template parameter?

I think these can be quality enhancements in the future:

3. Adopt more accurate machinery for _Thrd_sleep_for.
4. In wait_until, make sleep intervals more fine-grained if _Clock is not steady.

[achabense]

Though a bit off-topic, I think it's not harmful to make a push to add if constexpr in these places in this pr:

STL/stl/inc/__msvc_chrono.hpp

Lines 428 to 439 in fc444ce

	constexpr bool _Num_is_one = _CF::num == 1;
	constexpr bool _Den_is_one = _CF::den == 1;
	if (_Den_is_one) {
	if (_Num_is_one) {
	return static_cast<_To>(static_cast<_ToRep>(_Dur.count()));
	} else {
	return static_cast<_To>(
	static_cast<_ToRep>(static_cast<_CR>(_Dur.count()) * static_cast<_CR>(_CF::num)));
	}
	} else {
	if (_Num_is_one) {

[StephanTLavavej]

In my opinion, the separately compiled code should generally be a thin wrapper over the Windows API. Except when we need modifiable global state, the purpose of the DLL/LIB is to avoid dragging in <Windows.h> - we prefer to have as much code as possible be header-only. (Older code didn't adhere to this discipline which is where a lot of our problems come from.)

[AlexGuteniev]

we prefer to have as much code as possible be header-only

<charconv> tables seem to disagree.

[StephanTLavavej]

I originally implemented them header-only! 😸 (And while there are throughput advantages to separately compiling them, there are also costs - we will never be able to remove them even after switching algorithms.) Basically there are always reasons for special exceptions, but that's the general rule - code in headers is more flexible and less burdensome for maintenance.

[S0SLA]

By achabense:

I’m sorry that I cannot take part in development these days. Before this I’ve made a feedback branch to 1. make _Thrd_sleep_for a direct call to Sleep. 2. merge _Reltime… template into sleep_for, as I think its too early to generalize this utility. Please help mark this pr work in progress temporarily, I will go back as soon as I have time(maybe several days later).
As to the constexpr if, I think it would be nice to make an issue for some newcomers to do the contribution.

[StephanTLavavej]

Yes, after a brief glance the direction of that branch looks good to us; by the way, we now use __stdcall in new code because it's slightly more efficient (smaller code size since the callee pops instead of the caller), we should follow this convention even though it means that the declaration will differ compared to the nearby shared_mutex support functions.

[achabense]

There are still the following functions:

_CRTIMP2_PURE int __cdecl _Mtx_timedlock(_Mtx_t, const xtime*);
_CRTIMP2_PURE int __cdecl _Cnd_timedwait(_Cnd_t, _Mtx_t, const xtime*);

I think we should either not resolve the original issue or create a follow-up issue.

I've changed my pr description to avoid closing the original issue.

[achabense]

Can we also add back the piece of test mentioned in #1642?

[CaseyCarter]

I'll push changes for these nearly non-functional comments.

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[StephanTLavavej]

🧵 💤 ⏰

[Mike4Online]

Incidentally, this change appears to be a breaking change. I recently built the azure-sdk-cpp and aws-sdk-cpp libraries (for Azure Blob Storage and AWS S3, using vckpg port names azure-storage-blobs-cpp and aws-sdk-cpp[core,s3,s3-crt], respectively) using vcpkg on a Windows 10 system running Visual Studio 2022 Build 17.9. I then tried to build a DLL that links with these (now pre-built) static libraries on a different PC that was running Visual Studio 2022 Build 17.8. I got linker errors:

    49>azure-storage-blobs.lib(blob_responses.cpp.obj) : error LNK2019: unresolved external symbol __Thrd_sleep_for@4 referenced in function "void __cdecl std::this_thread::sleep_until<struct std::chrono::steady_clock,class std::chrono::duration<__int64,struct std::ratio<1,1000000000> > >(class std::chrono::time_point<struct std::chrono::steady_clock,class std::chrono::duration<__int64,struct std::ratio<1,1000000000> > > const &)" (??$sleep_until@Usteady_clock@chrono@std@@V?$duration@_JU?$ratio@$00$0DLJKMKAA@@std@@@23@@this_thread@std@@YAXABV?$time_point@Usteady_clock@chrono@std@@V?$duration@_JU?$ratio@$00$0DLJKMKAA@@std@@@23@@chrono@1@@Z) [D:\work\DevJenkins\Windows\MetaDataCacheLib\MetaDataCacheDll\MetaDataCacheDll.vcxproj]
    49>azure-core.lib(retry_policy.cpp.obj) : error LNK2001: unresolved external symbol __Thrd_sleep_for@4 [D:\work\DevJenkins\Windows\MetaDataCacheLib\MetaDataCacheDll\MetaDataCacheDll.vcxproj]
    49>aws-cpp-sdk-core.lib(ub_core.cpp.obj) : error LNK2001: unresolved external symbol __Thrd_sleep_for@4 [D:\work\DevJenkins\Windows\MetaDataCacheLib\MetaDataCacheDll\MetaDataCacheDll.vcxproj]

As soon as I upgraded my other PC to Visual Studio 2022 build 17.9 the link succeeded.

FYI.

[AlexGuteniev]

using vcpkg on a Windows 10 system running Visual Studio 2022 Build 17.9. I then tried to build a DLL that links with these (now pre-built) static libraries on a different PC that was running Visual Studio 2022 Build 17.8

This is expected.
Mixing multiple ABI compatible versions is supported, but the STL binaries should always be from the latest version in this case.

[StephanTLavavej]

Yep. This is documented at https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170 .