Wait on a set of operations without committing to any

[ghost]

This PR adds methods Select::{try_ready,ready,ready_timeout}, which wait on a set of operations until any one of them becomes ready. However, after that we're not obliged to "complete" the operation.

cc @Munksgaard @laumann This would help in resolving Munksgaard/session-types#45

Closes #222.

If anyone thinks we should name these methods differently, speak up! :)

[ghost]

cc @tecywiz121 @matklad You might like these new methods for dynamic selection, too!

[ghost]

To illustrate, here's how you can use this API:

let mut sel = Select::new();
sel.recv(&r1); // has index 0
sel.recv(&r2); // has index 1
sel.send(&s3); // has index 2

match sel.ready_timeout(Duration::from_secs(1)) {
    Err(_) => println!("timed out"),
    Ok(0) => println!("r1 is ready"),
    Ok(1) => println!("r2 is ready"),
    Ok(2) => println!("s3 is ready"),
    Ok(_) => unreachable!(),
}

[Munksgaard]

Oooh, that looks very promising! I'll take a closer look later today, but I'd be very excited to use this in session-types!

[Munksgaard]

With regards to the naming, I think the current schema is pretty good 👍

[ghost]

A sort of related question: do you think Select::remove() would be a useful method to introduce? For example, then you could call sel.remove(index) to remove a previously added operation.

[laumann]

I think @Munksgaard already did the best possible testing of: actually using it 😛 Looks good, it'll definitely simplify the session-types select implementation.

A sort of related question: do you think Select::remove() would be a useful method to introduce?

For our use case, I don't think so.

[ghost]

Thanks for your feedback, @Munksgaard and @laumann! I'm happy to hear this feature proved to be useful! :)

Let's merge and I'll publish a new version soon.

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[tecywiz121]

I'm a little late to the party, but how about having each send and recv return something like mio's Token?

That way you don't have to guess at the index, and you get some type safety?

[ghost]

@tecywiz121 That makes sense. I'll consider this change for the final set of breaking changes before version 1.0 early next year.

Which one of these you prefer?

1. fn recv<T>(&mut self, r: &Receiver<T>) -> Token
2. fn recv<T>(&mut self, r: &Receiver<T>, token: Token)

I kind of like that Select behaves like a Vec with simple indices, though.

[tecywiz121]

Yeah, I don't really mind using plain integers either.

Both options are appealing. The first one is nice because the library takes care of assigning tokens and it should make bookkeeping easier. The second option allows an application to define all their tokens up front statically, and not have to wait to use them.

I guess my preference depends on the distance between where send is called and where the Token is matched. If it's more likely that the tokens will get created and used immediately and discarded after, I think I prefer option 1, but if it's likely that tokens get reused and spread out over multiple files, I think option 2 is better.