Select on newrt pipes

[bblum]

Main logic in Implement select() for new runtime pipes.. The guts of the PortOne::try_recv() implementation are now split up across several functions, optimistic_check, block_on, and recv_ready.

There is one weird FIXME I left open here, in the "implement select" commit -- an assertion I couldn't get to work in the receive path, on an invariant that for some reason doesn't hold with SharedPort. Still investigating this.

[brson]

I still haven't fully digested this, but here are a couple of observations:

The commented out assertions in the comm code is worrying.

It looks like all of rt::select is intended to be a public API, so will eventually more likely live at std::select. Nothing in the API is tied to pipes, which is good, but Select itself exposes both Scheduler and BlockedTask, and both of these types are runtime implementation details and should not be part of the public interface. What are our options for hiding these types from the select API?

[bblum]

Oh yeah, the trait. Probably the thing to do is to have rt::select, which exports the trait as a non-pub module to only the rest of libstd, and have std::select which exports the select function.

[brson]

I still don't see how to encapsulate this into a public select api that doesn't expose runtime internals, at least one that is generic over multiple types of selectable things.

[bblum]

If I am not mistaken, as long as the trait Select and trait SelectPort<T> are not themselves pub, then they won't expose runtime internals, but users will still be able to take advantage of the typeclass when calling select functions.

If I am mistaken, we can at least do something like:

trait SelectInner { ... runtime internals ... }
pub trait Select : SelectInner { }
trait SelecPortInner<T> { ... runtime internals ... }
pub trait SelectPort<T> : SelectPortInner<T> { }

[brson]

Regarding the suggestion of how to hide the runtime internals, I'm not comfortable with the idea of mentioning types that aren't public in the signature of other public items (and kind of think that it's a wart that Rust allows it at all). This isn't a pattern we use anywhere else, and would need some wider discussion to determine if that's ok.

[glaebhoerl]

Wouldn't it be enough for the traits' methods to be private, and not the traits themselves?

[bblum]

True, I can't really imagine it would look very friendly in the documentation, either. Seems like the SelectInner thing is the way to go.