Skip to content
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

Evaluate/Improve desirability of a reusable ReadClient and the attendant lifetime-management complexity being foisted on the SDK consume #5446

Closed
yunhanw-google opened this issue Mar 18, 2021 · 2 comments
Assignees
Labels
stale Stale issue or PR V1.X

Comments

@yunhanw-google
Copy link
Contributor

I question the desirability of a reusable ReadClient and the attendant lifetime-management complexity being foisted on the SDK consumer. There are various things we could do to make this better, and some of them can probably be done on top of this PR, so I'm not going to block it, but I think we should very seriously think about something that would be both safer and easier to use.
For example, we could have a ReadClientHandle that allows move-construction and move-assignment only, except from inside the IM engine. The handle would point to a client and vice versa, with destructors cleaning up the references, and the move stuff on handle updating them. You could compare a handle to a client pointer, and you could shut the client down via the handle, but that's all you could do with a handle. When the client is done, it would shut itself down and null out the handle. This would guarantee that (a) you don't have to worry about shutting down the read client unless you want to terminate an in-progress read and (b) you can't mess up and shut down a different read from the one you meant to shut down because you kept a pointer to something around past a certain point. Please strongly consider filing a followup bug on this.

#5198 (review)

@stale
Copy link

stale bot commented Jul 25, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale stale bot added the stale Stale issue or PR label Jul 25, 2022
@stale
Copy link

stale bot commented Oct 18, 2022

This stale issue has been automatically closed. Thank you for your contributions.

@stale stale bot closed this as completed Oct 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Stale issue or PR V1.X
Projects
None yet
Development

No branches or pull requests

2 participants