On 15 Jan 2014, at 9:35 am, Eric Reed <[email protected]> wrote:
> I'm skeptical about combining Chan and SharedChan. Maintaining that
> distinction is useful for expressing the programmer's intent and would
> certainly make any analysis that cared to distinguish between single and
> multiple producers easier to implement (off the top of my head, knowing
> you're the only one with a Chan means you don't have to deal with potential
> race conditions arising from interleaving of messages from different
> producers). Maybe a SharedChan should be constructed by consuming a Chan and
> upgrading its queue rather than duplicating all of Chan constructors?
Perhaps there could be a simple `UniqueChan` type like:
~~~
struct UniqueChan<T> {
priv chan: Chan<T>,
}
impl<T: Send> UniqueChan<T> {
// Re-implement Chan methods here
}
impl<T> Drop for UniqueChan<T> {
fn drop(&mut self) {}
}
~~~
But that is the special case rather than the general case, which is why it
might be better to make Chan shared by default.
~Brendan
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
