Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Finish the Chan/Port types #10459

Closed
3 tasks done
alexcrichton opened this issue Nov 13, 2013 · 1 comment
Closed
3 tasks done

Finish the Chan/Port types #10459

alexcrichton opened this issue Nov 13, 2013 · 1 comment
Labels
A-concurrency Area: Concurrency A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows
Milestone
1.0

Comments

@alexcrichton
Copy link
Member

Right now these types have a few shortcomings, all of which need to get addressed for 1.0. Some specific problems with these types:

  • try_send/try_recv are bad names for what they actually do. Right now they will block and then return None when the other side disconnects. send/recv on the other hand will block, and fail!() if the other side disconnects. Almost everyone expects try_send/try_recv to not block and immediately return (returning whether there was something on the channel/port). We want both modes of operations, but clear names for them.
  • querying whether the other side has been disconnected. This is similar to the above point, but possibly distinct depending on the choice of functions. A channel should be able to query whether the other side has hung up or not.
  • Seamlessly work on and off the runtime. I should be able to create a stream anywhere in any situation and have it "just work" what this really means is that when we're on the runtime, we use the scheduler to block. When we're off the runtime, we use a native condition variable to block. This supports the "Communication" portion of Support 1:1 Scheduling #10493.
This was referenced Nov 13, 2013
Closed
Closed
Closed
@alexcrichton
Copy link
Member Author

Closed by #10830

flip1995 pushed a commit to flip1995/rust that referenced this issue Jun 30, 2023
@bors
Auto merge of rust-lang#11042 - y21:issue10459, r=Manishearth
750c7a1 
[`unused_async`]: don't lint if function is part of a trait

Fixes rust-lang#10459.

We shouldn't lint if the function is part of a trait, because the user won't be able to easily remove the `async`, as this will then not match with the function signature in the trait definition

changelog: [`unused_async`]: don't lint if function is part of a trait
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-concurrency Area: Concurrency A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows
Projects
None yet
Milestone
1.0
Development

No branches or pull requests
1 participant
@alexcrichton