Why Expirable-LRU delete Close method？
Super-long opened this issue · comments
In using Expirable-LRU it was found that if we wanted to dynamically close Expirable-LRU, a deleteExpired goroutinue would remain. and it looks like this can be done by simply deleting the done channel, but I noticed that in the 575866d commit to remove the close method, what is the reason for doing this?
I'd like to add this for expirable-lru, but I don't know why the code is commented out here, and there's no mention of the reason in the commit message https://github.com/hashicorp/golang-lru/blob/main/expirable/expirable_lru.go#L277
I have come here with the same issue. It seems it was implemented in #116 by @paskal, but can't understand why the close option was removed.
expirable.NewLRU should probably receive a context so we can have control over that goroutine that is started as a replacement to .Close if it is going to be removed.
This has come up because all my tests automatically check for leaking goroutines by ensuring the number of goroutines at the beginning of the test is the same as it is at the end, and without being able to call a cancel() on a context passed to the LRU goroutine the tests will keep failing.
Please see #116 (comment) for the reasons I removed it, it was a requirement for merging as I understood it.
Thanks, hadn't spotted that.
Would have to think about it, I understand the @mgaffney's point. Adding a context would allow some control over the goroutine without it being an official method of the cache, but does feel like another workaround. Maybe there is a need for a workaround though, leaking goroutines isn't ideal.
At least with a context or the Close() we have some control over the issue. An issue from closing without properly handling the other functions calling the cache is a user error in implementation of the cache that can be rectified, or shouldn't occur in the first place if implemented per the documentation. Whereas a leaking goroutine is a code error in the library rather than a user error and one that can't be fixed by the user or worked around.
It would be great to have this, as running code with the -race detector currently fails due to this issue. I think it would be better to add a .Close() method to let the user call that when they are done (opposed to runtime.SetFinalizer as in the linked PR).