Skip to content

Implement more communication primitives #1255

Closed
@boggle

Description

@boggle
Contributor

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

Activity

boggle

boggle commented on Apr 7, 2012

@boggle
ContributorAuthor

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.

ghost assigned on Apr 12, 2012
ghost assigned on Jul 6, 2012
eholk

eholk commented on Jul 25, 2012

@eholk
Contributor

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

boggle commented on Aug 4, 2012

@boggle
ContributorAuthor

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

pcwalton commented on Aug 7, 2012

@pcwalton
Contributor

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

eholk

eholk commented on Aug 7, 2012

@eholk
Contributor

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

added a commit that references this issue on Aug 24, 2022

Merge pull request rust-lang#1255 from afonso360/abi-checker

8c407e0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-concurrencyArea: ConcurrencyA-runtimeArea: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflowsC-enhancementCategory: An issue proposing an enhancement or a PR with one.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @boggle@eholk@brson@pcwalton

        Issue actions

          Implement more communication primitives · Issue #1255 · rust-lang/rust