If i assign the listener to a file level variable outside the method, and clear it inside awaitClose...

# coroutines

[myanmarking]

If i assign the listener to a file level variable outside the method, and clear it inside awaitClose, it does work

[streetsofboston]

I think it is because the compiler optimizes the listener variable out. It just assigns the listener as the argument to the start method.

This means the Listener instance reference goes out of scope. The start only keeps a weak-reference. Which means that no-one is keeping a hard reference anymore and it gets gc-ed

[myanmarking]

even in debug builds. hm. it may be that. any workaround ?

[streetsofboston]

BTW: I don’t like APIs at all that keep weak-references to callbacks and listeners. And what you experience is one of the reasons.

[myanmarking]

yes, but i cannot change the API. That was my initial proposal

[streetsofboston]

awaitClose { listener = null } may work?

[myanmarking]

to try it out, i keeped a static reference. It worked. Maybe a reference inside the callback will work as well. will try. thanks

[streetsofboston]

I don’t think that will get optimized out and will keep the reference to the Listener instance through the listener variable, until `awaitClose`’s lambda is called

[myanmarking]

it’s hard to reproduce, since i must run it in a loop and hope the GC kicks in in the middle. I didnt found any other way

[streetsofboston]

Be careful using static/global vars like that… you may introduce leaks if you are not careful.

[streetsofboston]

Did you try awaitClose { listener = null }?

[myanmarking]

yes i know. That was just to test my theory about the GC. I didnt knew the cause

[tseisel]

Some listener APIs may only keep weak references to the listener object, hence GC clears it when it is no longer referenced. That's the case with Android's SharedPreferences.OnPreferenceChangeListener I think

[louiscad]

You should unregister your listener in the awaitClose lambda anyway (or you create a leak for cases where the reference behind is a regular one). By doing so, that problem will go away.

[myanmarking]

yes, except the api has no way of unregistering

[louiscad]

Ah, what a bad API…

[louiscad]

Anton solution should work

[myanmarking]

yes, it was compiler optimization in the end. i got it thanks

[louiscad]

It's a recent one, it was introduced in 1.4.20