You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem: A breaking change made in Go 1.16, 2.5 years ago, and is ongoing. It affects Windows users. See Issue #44343 for details and links to other issues for the same problem.
Discussion: This proposal would help to mitigate the problem. It would make it much easier for a user, unfamiliar with Windows system calls, to use timeBeginPeriod and timeEndPeriod, which have been identified as a workaround. Using these, a user could manually set the system clock to the desired resolution, typically 1ms or 15.6ms. This workaround has been determined to not interfere with the current Go runtime. It has been tested by multiple people and found to work.
The text was updated successfully, but these errors were encountered:
In general it's always fine to add new functions that call standard Windows functions to x/sys/windows. That can be done without a proposal. A proposal is only required if it's not a standard Windows function, or if the function can't be called in an ordinary way (perhaps it requires a special data structure or something). That doesn't seem to be the case here, so taking this out of the proposal process. Thanks.
ianlancetaylor
changed the title
proposal: x/sys/windows: Expose timeBeginPeriod and timeEndPeriod
x/sys/windows: Expose timeBeginPeriod and timeEndPeriod
Aug 4, 2023
Problem: A breaking change made in Go 1.16, 2.5 years ago, and is ongoing. It affects Windows users. See Issue #44343 for details and links to other issues for the same problem.
Discussion: This proposal would help to mitigate the problem. It would make it much easier for a user, unfamiliar with Windows system calls, to use timeBeginPeriod and timeEndPeriod, which have been identified as a workaround. Using these, a user could manually set the system clock to the desired resolution, typically 1ms or 15.6ms. This workaround has been determined to not interfere with the current Go runtime. It has been tested by multiple people and found to work.
The text was updated successfully, but these errors were encountered: