what are some candidate data structures in that case? i'm happy to try and hack out some prototypes for that.
On Tue, Dec 31, 2013 at 4:41 PM, Patrick Walton <[email protected]>wrote: > On 12/31/13 1:33 PM, Nathan Myers wrote: > >> On 12/30/2013 08:58 PM, Patrick Walton wrote: >> >>> I'm not particularly interested in sacrificing performance by not >>> implementing one or the other in libstd. I think it's clear we need >>> both forms of channels, and they should be first-class primitives. >>> >> >> It's clear there are people who *want* both kinds of channels. It >> does not follow that they should both be first-class primitives. >> The possibility of precisely defining the behavior of a bounded >> channel in all circumstances is what makes it suitable as a >> first-class primitive. (The other, practical, requirement on >> primitives is that their number be minimal.) >> > > Unbounded channels have defined behavior as well. Undefined behavior has a > precise definition and OOM is not undefined behavior. > > > To implement an unbounded channel requires inherently more complex >> operations -- re-allocations or segmented storage, response to failure >> -- and corresponding choices that leak consequences visible to users. >> > > I don't think that a fixed size buffer is necessarily the right > implementation strategy for a bounded channel. There are cases in which you > want a bounded channel so that you don't OOM, but with a large bound. Those > use cases are not well served by always allocating the maximum size up > front (see Alex's slides for how slow implementations based on fixed-size > channels can get during channel creation with a large bound). > > > In an application with extreme constraints on performance, the >> arbitrary choices that must be taken implementing any particular >> unbounded-channel design are likely not to match requirements, with >> the typical result that such an application uses a private >> re-implementation. In the remaining, less demanding applications, >> there is no penalty for using an unbounded channel constructed from >> other, first-class primitives. >> > > Bounded channels can be constructed from unbounded channels as well, so I > don't see how this is an argument for making bounded channels the primitive. > > Patrick > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
