-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adjust behavior of conflated channel to match use-case of intermediate values #1235
Comments
elizarov
changed the title
Adjust behavior of ConflatedChannel to match use-case of intermediate values
Adjust behavior of conflated channel to match use-case of intermediate values
May 31, 2019
elizarov
added a commit
that referenced
this issue
May 31, 2019
elizarov
added a commit
that referenced
this issue
Jun 3, 2019
elizarov
added a commit
that referenced
this issue
Jun 4, 2019
qwwdfsad
added a commit
that referenced
this issue
Aug 7, 2019
…duce. Previously it was not possible due to not implemented #1235
qwwdfsad
added a commit
that referenced
this issue
Aug 9, 2019
…duce. Previously it was not possible due to not implemented #1235
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See long discussion in #332. Here is TL;DR. Current behavior of
Channel(CONFLATED)
(ConflatedChannel
) can be demonstrated with the following code (play):What happens here is that closing a channel is considered to send a "value" that overwrites last sent value. This is subtle behavior and it is not clearly spelled out in docs. In fact, on can argue that docs imply a different behavior. Anyway, this is not what one wants when conflated channel is used to send intermediate values of some computation. In this case one needs to ensure that the most recent value is always delivered. This use-cases seems to be most prominent one and this proposal is to change behavior of conflated channels to match it, so that the above code prints 1 and 4.
The text was updated successfully, but these errors were encountered: