-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Attempt to unbreak test timeouts in Windows. #4622
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
cc @compnerd |
In fact, I don't actually think doing this is correct, I think just dividing by the various units is more correct. The kicker is, of course, |
This shouldn't bite OpenBSD 7.1 and may fix regressions on Windows. The underlying time code is still a little suspect, but this might be the safest thing to do right now.
78cf8fd
to
cec57d4
Compare
What's still confusing me is that while the clock resolution on Windows is different, "fixing" the incommensurability of TSR units and nanoseconds actually broke Windows. To try to avoid spending too much time loading this stuff back into mental cache to try and untangle this, the safest course of action may be to just revert the attempt to fix #4220. This shouldn't bite OpenBSD now clock_getres is returning 1 like @compnerd, please try picking this and seeing if the test timeout troubles you no longer. |
Triggered a build, should hopefully know in 90m. |
Okay, this does seem to restore the Windows builds. |
@swift-ci please test |
Just finally confirmed the Foundation RunLoop tests pass on OpenBSD, so this is good to go when ready:
|
Thanks! |
On Windows, __CFTSRRate is in units of 100 ns. To get a CFTimeInterval
from mach_absolute_time therefore, we should divide by 1.0E7, not 1.0E9.
But this suggests we should be dividing by __CFTSRRate anyway.
(Currently trying to test this now, so making this a draft pr for now to share since #3004 may be causing trouble for Windows.)