Repository navigation
Consider implementing Singularity's channel contracts #2157
Description
In Singularity channels have the useful property that sending never allocates and never blocks. This should allow for a very simple implementation that our semantics don't.
There are some additional enabling properties (or limitations):
- Each channel has one sender and one receiver
- Each channel has a defined protocol (channel contract) that must be obeyed
Based on the contract they statically know the maximum number of elements that any queue will hold so they always allocate exactly the right amount. The contract is verified dynamically.
Adopting Singularity-style channels has two potential benefits:
First, contracts on their own are a useful thing, particularly in a language that aims to be 'safe'.
More importantly though it allows the port to use a lock-free circular buffer for the queue. Improving messaging performance is really the only reason we would want to impose more restrictions on channels. Whether this optimization will really pay off in practice I am not sure - there are several other locks on the send and receive paths.
Still not sure this is the right thing to do as it will create more barriers in channel usability, but maybe higher-level abstractions could be built on top.
Activity
boggle commentedon Apr 8, 2012
I see the implementation benefits but in this approach
Sure these things can be emulated with helper tasks. However channel semantics that directly correspond to network realities simplify re-using of existing code in a distributed setting. If channel and network semantics differ, it can be very hard to put existing software on the network that relies on channel guarantees the network cannot provide without difficulties.
A middle ground may be providing different channel types that at least document what guarantees are expected.
nikomatsakis commentedon Apr 8, 2012
This doesn't seem to me that it has to be an "either/or" thing. We can have a simple but flexible form of channels (as in #2158) and a highly optimized, contract-driven form of channels. I don't think it'd be too much of a burden to maintain two channel implementations---or maybe one can be based on the other, as brson suggested---but I'd want to make sure we have a need for both of them. I'd be inclined to start with the simple, flexible form (perhaps as in #2158) and wait until we hit a roadblock for Servo or some other project where messaging performance is a bottleneck. At that point, we might think about refactoring.
boggle commentedon Apr 8, 2012
Yes, I agree. I just think it is quite important to get the set of operations over channels right from the start as much as possible (#1255, broadcasts, timeouts), attach precise and reasonable semantics to the abstraction (perhaps using interfaces) that does not leak the implementation strategy, and provide enough support for using it without being a queueing theory expert ;). These are different issues but I think it is critical to get them right and a good idea to look more at erlang (which has proven that it works) than to look at go (which kind-of still has to).
From that angle, I'd like rust to somehow (flags, types, interfaces, typestate) differentiate between wether
and provide a few additional ops (timeouts, broadcasts).
eholk commentedon Jul 6, 2012
I've been working on implementing Singularity-style channel contracts. As of 7b03832, there is basic support for it in the compiler. I have a post describing it at http://theincredibleholk.wordpress.com/2012/07/06/rusty-pipes/. The proposal for channel contracts is also available at https://github.com/eholk/rust/wiki/Proposal-for-channel-contracts. So far the performance has been quite good. I'm going to be working on converting more code over to use them to get a feel for whether they are usable.
eholk commentedon Jul 25, 2012
We have these now, so I'm going to close the bug. We could use more syntax extensions, and the pipe compiler needs to be more robust, but basic support is there.
I intend to try and replace all of the existing Rust communication code with things based on channel contracts, and then hopefully remove the
commmodule.Auto merge of rust-lang#2157 - RalfJung:tests, r=oli-obk
squashing: recommend --keep-base when squashing without a conflict (r…
squashing: recommend --keep-base when squashing without a conflict (r…
Merge pull request rust-lang#2157 from xonx4l/stdarch-gen-common
Remove forcing \n via rustfmt