-
Notifications
You must be signed in to change notification settings - Fork 521
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
Allow that the renamed blocker thread is terminated #3728
Allow that the renamed blocker thread is terminated #3728
Conversation
Thanks! Can we actually apply this patch to the 3.5.x branch? Then we'll merge it up into 3.x. Hopefully that should avoid it being clobbered by a merge again... |
1e91a9b
to
57ebc46
Compare
Changed branch and cherrypicked. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not clear to me how could the blocker thread exit: the runtimeBlockingExpiration
is 1 minute by default. Could this test take such a long time?
That's an interesting point. Since we are making a custom |
Yeah, that's exactly what I was thinking about. It's exposed here: https://github.com/typelevel/cats-effect/blob/series/3.5.x/core/jvm/src/main/scala/cats/effect/unsafe/IORuntimeCompanionPlatform.scala#L57 |
57ebc46
to
67b3275
Compare
Switched it to expire threads after 10 minutes. Let's see if this fixes it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
In WorkerThreadNameSpec, if the thread is readded to the compute pool, we still check that it has been renamed and has the correct index, but if the thread has been terminated in the mean time, that is ok as well.
Closes #3704