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.

Sign up for GitHub

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

Jump to bottom

Cache can't be garbage collected #3

Open
ebonetti opened this issue Jul 22, 2015 · 2 comments
Open

Cache can't be garbage collected #3

ebonetti opened this issue Jul 22, 2015 · 2 comments

Comments

@ebonetti
Copy link

Goroutine (associated with cache worker) prevent cache from being collected.
In my opinion there should be a way to stop it.
Alternatively, this fact should be documented.

Keep up the good work,
Enrico
@karlseguin
Copy link
Owner

Are you ok with the cache being unusable once Stop is called? Is panic'ing a little extreme or acceptable?

Consider: bfa769c

@ebonetti
Copy link
Author

Edited: there is a big problem with "deletables" channel: goroutines waiting to pass values are blocked..
In "worker", just before exiting goroutine, the Cache should be cleared (enforcing user to stop using it) and then close "deletables".
This way it panics on both channel on a send attempt, but in my opinion panicking isn't right..
Enrico

karlseguin added a commit that referenced this issue Jul 26, 2015
@karlseguin
Partially fixing #3.
74754c7 
On close, drain the deletables channel (unblocking an waiting goroutines) and
close deletables. Like Gets and Sets against a now-closed promotables,
this means any subsequent to Deletes from deletables will panic.

I'm still not sure that this is ccache's responsibility. If a client closes a DB
connection, we'd expect subsequent operations against the now-closed connection
to fail. My main problems with defer'ing a recover are:

1 - the performance overhead on every single get / set / delete
2 - not communicating with the caller that the requested operatin is no longer
    valid.
@hasheddan hasheddan mentioned this issue Nov 5, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@karlseguin @ebonetti