-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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 is_closed
, is_empty
and len
to mpsc::Receiver
and mpsc::UnboundedReceiver
#6348
Merged
Merged
Changes from 3 commits
Commits
Show all changes
15 commits
Select commit
Hold shift + click to select a range
48587f8
Add `is_closed` to `mpsc::Receiver` and `mpsc::UnboundedReceiver`
balliegojr be9bbeb
fixes documentation links
balliegojr ccecf35
splits is_closed tests into multiple smaller tests
balliegojr c1c870b
add is_closed tests for unbounded channel
balliegojr e655f9e
Add permit test for Receiver is_closed function
balliegojr 2d964a2
fix wrong permit comments in Receiver is_closed tests
balliegojr 816aea7
move empty channel check into is_empty function
balliegojr 8a3851a
remove mut requirement from the is_empty function
balliegojr ab5278b
add len function to bounded and unbounded receivers
balliegojr 8d505dd
reduces the unsafe scope in the len function
balliegojr 1e50d9f
fixes the is_empty function
balliegojr d5b1b1f
Merge branch 'master' into receiver-is-closed
balliegojr fbd1794
refactor mpsc list len and is_empty functions
balliegojr 6537a80
add missing rx len test scenarios
balliegojr ba1ccb3
Merge branch 'master' into receiver-is-closed
balliegojr File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Darksonn marked this conversation as resolved.
Show resolved
Hide resolved
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's a lot of tests! That's awesome. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
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.
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.
I am not 100% happy with this name, since in the end it also checks for outstanding messages in channel buffer
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.
So I was going through this one more time and I realized that you may be right here. Currently, it's possible to have a situation where
Sender::is_closed
returns true butReceiver::is_closed()
returns false. That's probably not desirable. It probably makes more sense to change it to match the existing method on the sender.Of course, another option is to rename this method to reflect its actual behavior.
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.
Yeah, I totally agree with this. I think the
is_closed
should return true ifclose
was called or all the senders are dropped, regardless of having any messages available in the channel.I believe it would be a good idea to provide an additional function, maybe
is_empty
orhas_messages
, that checks if there are any messages available in the channel, this way the user would be able to check both conditions withrx.is_closed() && rx.is_empty()
.What do you think?
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.
That seems reasonable to me. Adding an
is_empty
method could make even more sense together with adding alen
method (which would close #6314). After all, clippy emits a warning if you addlen
withoutis_empty
.But if you only want to add
is_empty
, that's also okay.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.
I have added the
is_empty
andlen
functions.The
len
implementation only checks for thetail_position
. I am not sure if it is necessary to check theready
bits for valid values in each position, since that would be relatively costly because of the linked list implementationThere 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.
Hmm, regarding the ready bits, I guess the main question here is concurrency-related. For example, imagine if you have the following two threads running in parallel:
Then, depending on how you implement
len
, it's possible that the assertion could fail. This would happen if message1 ends up being stored after message2 in the channel queue, but when the assert runs, message2 is has not yet been fully sent.We once had a similar bug with
try_recv
. See #1997. Basically, this assert could fail:The assert would sometimes fail when message2 ends up before message1 in the queue. Here,
try_recv
can't return message1 because we guarantee that messages are returned in order. It also can't return message2 because the call tosend("message2")
is still running. So it returnsNone
instead, even though we know that a message has been successfully sent. When we fixed it in #4113, we did so by havingtry_recv
sleep untilsend("message2")
finished when there are fully sent messages later in the queue.To test this, you can add these loom tests:
I don't know whether these tests will fail, but if they do, please look at
try_recv
to see how it determines whether it should sleep or not.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.
Both tests failed. I am looking on how to fix 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.
I added both loom tests and fixed the
is_empty
implementation.About
len_nonzero_after_send
test, I think thelen
implementation was already correct, but I ran the wrong test initially.At first I had written the assertion
assert!(recv.len() == 2)
, which should fail since thejoin()
is after theassert!
.With the
assert!(recv.len() != 0);
assertion, the test passes