-
Notifications
You must be signed in to change notification settings - Fork 12.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
comm: Implement synchronous channels #12991
Conversation
/// This channel's receiving half has disconnected, so the data could not be | ||
/// sent. The data is returned back to the callee in this case. | ||
RecvDisconnected(T), | ||
} |
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 unsure if these are the best names.
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.
As far as I can tell, RecvUnavailable
could be considered a special case of Full
. How would you feel about collapsing them together?
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.
Sounds good to me.
This commit contains an implementation of synchronous, bounded channels for Rust. This is an implementation of the proposal made last January [1]. These channels are built on mutexes, and currently focus on a working implementation rather than speed. Receivers for sync channels have select() implemented for them, but there is currently no implementation of select() for sync senders. Rust will continue to provide both synchronous and asynchronous channels as part of the standard distribution, there is no intent to remove asynchronous channels. This flavor of channels is meant to provide an alternative to asynchronous channels because like green tasks, asynchronous channels are not appropriate for all situations. [1] - https://mail.mozilla.org/pipermail/rust-dev/2014-January/007924.html
This commit contains an implementation of synchronous, bounded channels for Rust. This is an implementation of the proposal made last January [1]. These channels are built on mutexes, and currently focus on a working implementation rather than speed. Receivers for sync channels have select() implemented for them, but there is currently no implementation of select() for sync senders. Rust will continue to provide both synchronous and asynchronous channels as part of the standard distribution, there is no intent to remove asynchronous channels. This flavor of channels is meant to provide an alternative to asynchronous channels because like green tasks, asynchronous channels are not appropriate for all situations. [1] - https://mail.mozilla.org/pipermail/rust-dev/2014-January/007924.html
…it-into-impl-root, r=Veykril Feat: extracted method from trait impl is placed in existing impl **Before** https://user-images.githubusercontent.com/1759192/183872883-3b0eafd2-d1dc-440e-9e66-38e3372f8b64.mp4 **After** https://user-images.githubusercontent.com/1759192/183875769-87f34c7d-52f0-4dfc-9766-f591ee738ebb.mp4 Previously, when triggering a method extraction from within an impl trait block, then this would always create a new impl block for the struct, even if there already is one. Now, if there is already an existing trait-less impl block, then it'll put the extracted method in there. **Caveats**: - It currently requires the target impl block to be non-empty. This limitation is because the current architecture takes a `node_to_insert_after` as reference for where to insert the extracted function. An empty impl block doesn't have such a reference node, since it's empty. It seems that supporting this requires a much larger and more complex change. - This is my first contribution in rust, so apologies for any beginner mistakes.
This commit contains an implementation of synchronous, bounded channels for
Rust. This is an implementation of the proposal made last January [1]. These
channels are built on mutexes, and currently focus on a working implementation
rather than speed. Receivers for sync channels have select() implemented for
them, but there is currently no implementation of select() for sync senders.
Rust will continue to provide both synchronous and asynchronous channels as part
of the standard distribution, there is no intent to remove asynchronous
channels. This flavor of channels is meant to provide an alternative to
asynchronous channels because like green tasks, asynchronous channels are not
appropriate for all situations.
[1] - https://mail.mozilla.org/pipermail/rust-dev/2014-January/007924.html