GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||
GeezerVison is showing github.com — feat: watch and subscribe to ACP session updates by hugodutka · Pull Request #30903 · coder/coder Conversation
|
| return r, nil, err | ||
| } | ||
| subscriber := &sessionSubscriber{ | ||
| events: make(chan workspacesdk.ACPEvent, 64), |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I'd like to avoid these pre-determined buffered channels that have unpredictable results. We already have a case in chatd where live streaming just halts because a channel becomes full. Leaving this as-is, there'd have to be a case for why 64 will never overflow, or why it's OK when it does. Ideally this would be a slice or an unbounded channel (e.g. slice-backed). Memory consumption may be a concern, although I find that unlikely.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Here the result is very predictable. If the subscriber lets the buffer overflow we remove it. This is a pretty standard pattern.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
And what happens after it’s removed? Would like to see the reasoning encoded in the code.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Added a comment to explain it.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
e43d28d to
152b431
Compare
cb95a04 to
66866e8
Compare
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Approving as-is with the caveat that it would be nice to clean up the subscriber implementation as a follow-up to be mutex or unbounded channel based.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
66866e8 to
28c97ff
Compare
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.