-
Notifications
You must be signed in to change notification settings - Fork 76
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
Windows bug? #70
Comments
I don't really have a way of checking right now, but from what I get from your message (and if I'm not misunderstanding) I'd say that it's to be expected for the timer to run sequentially. Since the event-loop is single-threaded, I don't see a way where the timers would run in parallel. Could you point me to the failing test in |
Not the cleanest repro. I think a simpler repro would simply start 2 timers in parallel, e.g. 1 for 10ms and another for 20ms, wait for both to complete, and test that no more than ~20ms has passed (i.e. should be <<30ms). The event loop is single-threaded but it can have many in-flight operations going at once. |
I'll try to investigate when possible. In the meantime, I think it's important to notice that timing on Windows is really hard to get right. If I'm correct, granularity is very high. For example, multiple milliseconds can pass when using the |
Understood, thanks for looking into it! Yeah, maybe test with higher
durations like 100ms and 500ms locally just to make sure.
…On Fri, Sep 29, 2023 at 2:25 AM Corentin Godeau ***@***.***> wrote:
I'll try to investigate when possible.
In the meantime, I think it's important to notice that timing on Windows
is really hard to get right. If I'm correct, granularity is very high. For
example, multiple milliseconds can pass when using the sleep function.
Maybe that's similar with the timeout given to the
GetQueuedCompletionStatusEx function that I use in the code.
—
Reply to this email directly, view it on GitHub
<#70 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIQMW3U64DKAS4VA3GEDOTX42HWZANCNFSM6AAAAAA5LH33GM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Hey @rsepassi I tried to reproduce the issue at home and it seems to be an issue of granularity. I had some adaptations to make due to latest Zig version. The The Unfortunately, I don't really know what can be done currently to improve timing precision on Windows, that was one of the limitation I mentioned in the PR 😕 I tested with Zig 0.12.0-dev.1261+bb0419599 |
The way to do higher resolution sleeps/waits in Windows is the multimedia timer API. This blog post explains a recent change to the framework and gives good information about timer resolutions in the process. https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/ |
Don't have a clean repro at the moment, but initial check of the Windows support indicated that 2 timers were running sequentially instead of in parallel; could very well have been holding it wrong, but the same code worked fine on Linux and Mac. cc @Corendos
Non-clean repro is the zigcoro test. https://github.com/rsepassi/zigcoro windows branch
The text was updated successfully, but these errors were encountered: