-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Add System.Threading.PeriodicTimer #53899
Conversation
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
src/libraries/System.Private.CoreLib/src/System/Threading/PeriodicTimer.cs
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/Threading/PeriodicTimer.cs
Show resolved
Hide resolved
👍 The usage of the new timer is not very different from a while loop with a Task.Delay(..) within. It is not very.. innovative. |
62b0e5d
to
9f819ab
Compare
9f819ab
to
b889608
Compare
Failures are https://github.com/dotnet/core-eng/issues/13324 |
…bugger2 * origin/main: (107 commits) Disable MacCatalyst arm64 PR test runs on staging pipeline (dotnet#54678) [WASM] Fix async/await in config loading (dotnet#54652) Fix for heap_use_after_free flagged by sanitizer (dotnet#54679) [wasm] Bump emscripten to 2.0.23 (dotnet#53603) Fix compiler references when building inside VS (dotnet#54614) process more TLS frames at one when available (dotnet#50815) Add PeriodicTimer (dotnet#53899) UdpClient with span support (dotnet#53429) exclude fragile tests (dotnet#54671) get last error before calling a method that might fail as well (dotnet#54667) [FileStream] add tests for device and UNC paths (dotnet#54545) Fix sporadic double fd close (dotnet#54660) Remove Version.Clone from AssemblyName.Clone (dotnet#54621) [wasm] Enable fixed libraries tests (dotnet#54641) [wasm] Fix blazor/aot builds (dotnet#54651) [mono][wasm] Fix compilation error on wasm (dotnet#54659) Fix telemetry for Socket connects to Dns endpoints (dotnet#54071) [wasm] Build static components; include hot_reload in runtime (dotnet#54568) [wasm][debugger] Reuse debugger-agent on wasm debugger (dotnet#52300) Put Crossgen2 in sync with dotnet#54235 (dotnet#54438) ...
Fixes #31525
I still wonder whether
IAsyncEnumerable<T>
would be a better way to expose this, e.g. astatic IAsyncEnumerable<TimeSpan> Periodic(TimeSpan period, CancellationToken cancellationToken = default);
as a static method onSystem.Threading.Timer
. One concern there was around what data we'd actually return as theT
, but I think an elapsed time since start or something along those lines could be reasonable, even if generally ignored. The other concern was around how one stops the enumeration from outside of the consuming loop (the consuming loop itself can just break out and dispose of the enumerator); I'm personally comfortable using the cancellation token for that purpose, but I know there were concerns about modeling such stopping as an exceptional situation. On the balance, I think that model is cleaner, and I like the idea of adding a new method to Timer rather than increasing the number of timer types we have.cc: @davidfowl, @terrajobst, @kouvel