-
Notifications
You must be signed in to change notification settings - Fork 41
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
Drain channel immediately after last receiver is dropped #23
Comments
This should be possible to do by applying a patch similar to crossbeam-rs/crossbeam@06d77d3 to concurrent-queue. |
tiagolobocastro
added a commit
to openebs/mayastor
that referenced
this issue
Mar 20, 2023
When creating a rebuild job we were reusing the same comms type which is used to do bi-dir communication between the rebuild frontend and backend. In some situaitons this could lead into blocking stats because the receiver channel was kept alive by the frontend even after the frontend terminates. Force closing the channel should in theory help but it seems the queue is not drained on close. See: smol-rs/async-channel#23 Instead, let's split the channels into two types meaning only the backend has the receiver side. Signed-off-by: Tiago Castro <tiagolobocastro@gmail.com>
tiagolobocastro
added a commit
to openebs/mayastor
that referenced
this issue
Mar 20, 2023
When creating a rebuild job we were reusing the same comms type which is used to do bi-dir communication between the rebuild frontend and backend. In some situations this could lead into blocking stats because the receiver channel was kept alive by the frontend even after the frontend terminates. Force closing the channel should in theory help but it seems the queue is not drained on close. See: smol-rs/async-channel#23 Instead, let's split the channels into two types meaning only the backend has the receiver side. Signed-off-by: Tiago Castro <tiagolobocastro@gmail.com>
Hi @taiki-e, is there any plan to resolve this issue? we have also encountered the abovementioned issue (with a similar usage). |
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After the last receiver is dropped, all the items in the channel are effectively abandoned and can never be accessed. In this scenario, I think it's appropriate to drain the channel and drop all the items. One use case where this is relevant is a dispatch mechanism that uses oneshot channels:
Here, if
worker
terminates while there are still requests in the channel,dispatch
can end up waiting for the response forever. This can be addressed with timeouts, but I think automatically draining the channel is a better solution.The text was updated successfully, but these errors were encountered: