First crack at a Streams proposal
Tab Atkins Jr.
jackalmage at gmail.com
Mon Apr 15 17:14:28 PDT 2013
On Mon, Apr 15, 2013 at 5:06 PM, Kevin Gadd <kevin.gadd at gmail.com> wrote:
> If this is really about multiple-consumer streams, the semantics of this
> proposed API are incredibly murky to me. What happens if each consumer calls
> next()? Do they all get the same value out of their Future when it's
> completed? Do they each randomly get one of the values pushed into the
> stream? Is the stream implicitly required to buffer data in order to be able
> to offer it at a slower rate to one consumer than it is offered to the other
> consumers? Does each consumer have a different 'view' of the state of the
> stream (i.e. its cancelled/ended state, when those concepts apply)?
Huh, I'm not sure what's unclear about it. (Though, obviously it must be.)
The future returned by Stream#next() resolves at the next update (or
when the stream completes/rejects). If multiple consumers call next()
repeatedly in the same tick (or in different ticks, but before an
update gets pushed), all of the futures resolve at the same time,
because they're all listening for the same "next update".
I'm not sure I understand how it could be required to buffer. Can you
describe the kind of situation you think would cause that need?
Same with view - perhaps you're thinking that the state can be updated
syncly, inbetween listen callbacks?
More information about the es-discuss