-
Notifications
You must be signed in to change notification settings - Fork 10.1k
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
Use reset event in Kestrel heartbeat to quickly stop thread #47619
Conversation
src/Servers/Kestrel/Core/src/Internal/Infrastructure/Heartbeat.cs
Outdated
Show resolved
Hide resolved
@mconnew This PR updates Kestrel heartbeat to exit immediately and stop before Kestrel starts shutting down. That removes the need to use Can you take a look and check that your original issue is still solved? |
@Tratcher I moved heartbeat stop to the start of shutdown. Can you double check this is ok? |
@JamesNK, it looks like it should resolve it as Dispose() won't return until it will no longer call OnHeartbeat. There's nothing preventing a later change bringing the issue back though as OnHeartbeat is internal so callable. In the catch block you could call WaitOne with a timeout of 0. You can then check the true/false value that's immediately returned to know if it's been set and still avoid logging. That would also enable you to keep the unit test you've removed. Also, why not ManualResetEventSlim? ManualResetEvent allocates a native win32 handle and the Slim variant is all managed. |
OnHeartbeat is only internal for unit tests. It won't be called after the heartbeat is disposed.
I read that slim implementation offers an advantage for short wait times, which doesn't apply here. |
So it sounds like it doesn't matter that much, but indeed it should avoid creating the OS object unless you explicitly fetch |
src/Servers/Kestrel/Core/src/Internal/Infrastructure/Heartbeat.cs
Outdated
Show resolved
Hide resolved
4f57f79
to
a502d1d
Compare
PR updated to use Added a test for the heartbeat loop. Previously wasn't tested. |
9d8cff5
to
b4a6c37
Compare
Fixes #47600
Replace
Thread.Sleep(1000)
withManualResetEventSlim
.