Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
After a brief discussion with @Darksonn about the precise behavior given by various methods of shutting down a
Runtime
(dropping it,shutdown_timeout
,shutdown_background
), I was experimenting with the available options to try to determine the differences between them.The issue
During this experimentation, I discovered that calling
rt.shutdown_timeout(Duration::from_nanos(0))
actually does wait until all blocking tasks finish, contrary to what would be expected. This is notably different from if we passedDuration::from_nanos(1)
instead, which has the effect of shutting down immediately. As best I can tell, this is a bug.Here's a sample program on the playground that demonstrates this behavior.
The solution
The issue seems to be that the implementation of the runtime's shutdown channel's
Sender::wait
is returningtrue
(indicating that the timeout duration has not been reached) when given a duration of zero. When that happens, we take extra steps that rely on those tasks having finished.Other things
This might be a breaking change - I wouldn't expect anyone to be directly relying on the behavior of
shutdown_timeout(0)
, but anyone usingshutdown_background
might suddenly find that certain tasks are unexpectedly terminated when it wasn't happening before. This is because the current behavior seems to be identical to simply dropping theRuntime
, which is more lenient than what the documentation ofshutdown_background
indicates.