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.

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

Implement more communication primitives #1255

Closed
boggle opened this issue Dec 3, 2011 · 5 comments
Closed

Implement more communication primitives #1255

boggle opened this issue Dec 3, 2011 · 5 comments
Labels
A-concurrency Area: Concurrency A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@boggle
Copy link
Contributor

boggle commented Dec 3, 2011

We are lacking at least one critical primitive:

  • recv on port<T> with timeout that returns an option<T>

It may be desirable to recv from multiple ports at once, which may need

  • recv on [port<T>] that returns (uint, T)
  • recv on [port<T>] with timeout that returns option<(uint, T)>
  • recv_some on [port<T>] with timeout that returns [T] or [(int, T)]
  • These calls assume a fixed message type, it would be nice if it was possible to
    recv from a set of differently typed ports at once and match on the result somehow

These calls perhaps would be useful for sending to many channels:

  • send_any(value: T, channels: [chan<T>]) that returns the uint vec index of the channel actually used
    • with the channel selected fairly from channels
  • send_ready(value: T, channels: [chan<T>]) that returns the uint vec index of the channel actually used
    • with the channel selected fairly among ready channels from channels
  • send_all(value: T, channels: [chan<T>])
    • for convenience
@boggle
Copy link
Contributor Author

boggle commented Apr 7, 2012

Things have become better thanks to recv2, std::time etc but there still is no true way to recv with a timeout. This likely needs support by the runtime.

@eholk
Copy link
Contributor

eholk commented Jul 25, 2012

This bug had a lot of pieces, which made it daunting and difficult to keep track of all that were done. I opened up a bunch of smaller bugs that reference this issue so we can keep track of them easier and keep them more manageable. Feel free to add comments about the desired semantics in all of them.

@boggle, I wrote the new bugs for the new protocol/pipe system, since I'm hoping to remove the port/chan system in favor of pipes. Does this work for you?

@boggle
Copy link
Contributor Author

boggle commented Aug 4, 2012

I sadly haven't come round to looking at pipes but as long as the functionality I asked for while be there I am happy with that. On a very different note, are you aware of the disruptor project? It is the first true innovation in concurrency I have seen in a while and I keep wondering how one would implement that in rust.

@pcwalton
Copy link
Contributor

pcwalton commented Aug 7, 2012

If all of the parts of this bug have individual bugs, can we close this one?

@eholk
Copy link
Contributor

eholk commented Aug 7, 2012

Sure, although having this one open does give us a convenient place to go find a list of all the related bugs.

@eholk eholk closed this as completed Aug 7, 2012
bjorn3 added a commit to bjorn3/rust that referenced this issue Aug 24, 2022
Add abi-checker to y.rs and run it on CI
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-concurrency Area: Concurrency A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

4 participants