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
