You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A live stream can stop (for whatever reason) either from the Protocol / Input layer, or from the Control layer. This bi-directional cancellation is currently a mess, and there's some hacky code in place to make it work.
Reasons for Cancellation
Control
Service / Orchestrator failure (unexpected or expected)
Control shutdown
Protocol / Input
Specific disconnect request
Network io error
Options
It seems like context may be appropriate for this, however I don't have a ton of experience using it.
Alternatively, depending on the Control architecture, we could use callbacks -- though that's not very "go" like.
The text was updated successfully, but these errors were encountered:
I have been reviewing the code around the current implementation. While it works, I think doing bi-directional cancellation is better done through the use of channels as well as context.
Generally, context is meant to be passed from a parent to derived tasks or subtasks. The parent is then responsible for cancelling any subtasks it may have created. Storing context in a struct is also frowned upon.
For clarity, here's what I have in mind.
When the cancellation is directed from the control to the session stream, there should be a parent context for OS signals which is propagated from main.go to the code responsible for handling new streams. This context is cancelled when server is killed/restarted.
When the cancellation is directed from the session stream to control due to bad io etc. the use of channels would be more appropriate. AFAIK, the stream type is responsible for cleanup/removal itself. Instead of propagating context from a child/spawned task to a parent task, we could use a oneshot channel to signal cleanup/cancellation to control.
I like the idea of using a simpler setup with channels and contexts. I implemented an experimental version of this in 3004b21 however they are stored in a struct. It didn't seem clear to me how to keep access to them over time and handle cancellation inside the inputs. Looking forward to seeing your improved implementation!
A live stream can stop (for whatever reason) either from the Protocol / Input layer, or from the Control layer. This bi-directional cancellation is currently a mess, and there's some hacky code in place to make it work.
Reasons for Cancellation
Options
It seems like context may be appropriate for this, however I don't have a ton of experience using it.
Alternatively, depending on the Control architecture, we could use callbacks -- though that's not very "go" like.
The text was updated successfully, but these errors were encountered: