I'm using an event queue based on a

Channel

like this:

val eventQueue = Channel<ApplicationInstallRequest>()

	init {
		initEventProcessor()
	}

	private fun initEventProcessor() = launch(Unconfined) {
		for (request in eventQueue) {
			processRequest(request)
		}
	}

	override fun onEvent(event: ApplicationInstallRequest) {
		eventQueue.sendBlocking(event)
	}

from an Android SyncAdapter, but even when the sync is finished, the process keeps on going (some kind of leak...), does Unconfined have it's own thread or something?

Android kills processes when it's out of RAM or when a non foreground, long running process consumes too much resources like CPU. So if the RAM pressure is low, it keeps the processes alive, so the apk don't need to be reloaded in RAM from storage again next time something is going on with this same app (like another sync session)

Right, but then all processes should be stopped...? The downloading is continuing even though the sync adapter stops and the attached service is killed.

Right, but then all processes should be stopped...?

No, you misread/misunderstood my statement (which is inspired from Android docs)

It would be fine if the Service was still alive... the problem is that the service is dead, and the process keeps running...

Anyway, do what is right in your app, understand the lifecycle of the components you use, and make your app do only necessary work. having a parent job that you cancel in methods like

onDestroy()

is a good idea also

So I don't have to kill it on

onDestroy

?

The process just sits there in case the service or any other component in your app is started again, so it's not needed to load the apk from scratch back again

Meaning cancel the coroutine (and the download)

kill and cancel are not the same things

The problem is that they only run after

onDestroy

, which was my problem in the first place 🤕 , so the download won't run... I think I'm doing something wrong with coroutines...

I'm not sure what you're trying to do, but I think you're going overcomplicated, probably because there's something you didn't fully grasp. If you can tell me what you're using coroutines for in this problematic case, I can probably help you

I'm trying to download files in parts, as part of a bigger sync process, and a sync might be started from another service at the same time. I'm using the channel as a barrier that only one download should run at a time. (Afterwards I was planning to check for each request if that same file is already underway and check if the user cancelled download on that request...

@dave08 Can the user manually cancel the download, and is it tied to the same mechanism you are trying to use for cancelling when the sync adapter or the service is destroyed?

No, he can only cancel by running the sync again (not my code, I'm stuck with that api for now..)

So what you need is either a

Mutex

(from kotlinx.coroutines, which suspends instead of blocking), which you put in a top level val or in an

object

, or an

actor

. And not a big deal if sync continues after the service or sync adapter is stopped. If there's not internet, it will fail and stop by itself, and if the system really needs the resources, it will throttle or kill the process

But any reference to the application context won't fail? I tried actors, it gets very messy with tons of extra classes with all the different requests and responses. And completable deferreds... the new actors look much better simple smile , I hope they'll come out soon...

@dave08

sendBlocking

doesn't suspend but blocks while the underlying

send

is suspended (if

offer

didn't work in the first place). You shall never use

sendBlocking

from a coroutine

I stand corrected 🙂, in my case, that's what I needed since I'm running in a background thread in a

Service

...

In the same use cas, I use

offer

and it works perfectly

offer

has different behaviors following the type or capacity of the channel though, it's important to be sure it's right for the use case