with a queue for coroutines (using a semaphore) is there a way to manually assign a job id or an ide...

# coroutines

[Garret Yoder]

with a queue for coroutines (using a semaphore) is there a way to manually assign a job id or an identifier to the coroutine in the semaphore?

I'm looking to prevent duplicate jobs from getting created, and have a unique number for each task, and I'm trying to find a good way to make the UI not have to be aware of load states at all so if it calls the task creation method 50 times as a widget scrolls past and is recomposing, who cares.

to that end, I was hoping to be able to do something where I could assign an id or a secondary value to the coroutine, put it in the semaphore, and then before placing another coroutine check if that task ID already exists. So kind of like a unique stack of coroutines

[kevin.cianfarini]

I’m having a hard time following your question. When you say queue for coroutines, do you mean Channel?

[Garret Yoder]

No, I'm using a Semaphore to limit the execution of coroutines to n concurrently

[Garret Yoder]

you can spawn as many coroutines as you want and they will only execute with n amount concurrently

[Garret Yoder]

I'm just looking for an alternative to the Semaphore where I can check whats currently in the queue that hasn't been given a permit yet and just do nothing if the task already exists

[kevin.cianfarini]

To do so you’d need to track some kind of state for what defines a job is unique. Perhaps something like a MutableStateFlow<Set<Parameter>> would do the trick. You could then limit the amount of concurrent jobs spawned by that using a semaphore when collecting it.

[kevin.cianfarini]

Based on your use case though

creation method 50 times as a widget scrolls past and is recomposing, who cares

It sounds like you might actually be desiring job debouncing

[Garret Yoder]

I usually would track something like this via a state in the UI just for is the item loading or not (and then show some sort of indicator, etc)

however I've put myself in a unique position because I'm designing a very modular app that has completely self contained modules that manage their own everything, and merely supply the greater app w/ an object that extends a common interface

[Garret Yoder]

so I'm trying to keep everything very compartmentalized. And because this is going by pages, I can't just track an individual status for each item, a page can represent 1 item or 100 items. So tracking the load states is a bit difficult

[Garret Yoder]

This is why I've opted for just an object to represent an item that hasn't loaded yet, and it'll get swapped at a later time when a given page loads

so I'm trying to keep all of the load state management out of those actual objects