Juan F. Esteban Müller

@newville , thanks for accepting my PR. The reason why I assumed that the calls to count always return 1 is that the references to those callbacks are added by...

I may have missed something, but it seems to me from the code that `epics.PV.get_pv()` does not add callbacks into `epics.ca._cache`. Instead, callbacks are stored in the lists `epics.PV.callbacks`, `epics.PV.connection_callbacks`,...

Hello. Is there any reason why this hasn't been added yet? At ESS we are struggling with memory leaks that we think are caused by this. Adding a call to...

Hi again, I think I understand the issue now. I assume that ca.clear_channel() is not called because there can be more than one PV object connecting to the same channel...

Hi @newville, The issue arises when you create a new PV object and then call its disconnect method. Because ca.clear_channel() is not called, the resources are never released by the...

Sorry, I think the discussion is drifting away from the original issue... I believe the discussion on how my colleague should/shouldn't implement his code belongs to other forums (or at...

@newville I agree with your reasoning and am grateful to you for trying to help my colleague find a solution. However, in this case this seems to be a bug,...

The title of the issue says "ca.clear_channel **should** be called on PV.disconnect." I fully agree with that statement, and this is what I was suggesting in the first place. However,...

After some testing, I realized that there was another cache that was keeping references to methods of PV objects, thus preventing them being garbage collected. Those references are stored in...

Sorry, but I am getting a bit tired of the philosophical discussion. Regardless of what you expect disconnect to do, there is a **memory leak** in the code. I am...