I am trying to create a mechanism for background t...

# kotlin-native

[Prateek Grover]

I am trying to create a mechanism for background thread execution of functions in kotlin-native for iOS platform. I am using workers to do that. I have a couple of questions about the same:
1. Since we can also use dispatch_queue in ios part of kotlin-native multiplatform project, what is then the advantage to use workers?
2. Should I create a new instance of worker for every function call or should I use a pool?

[Artyom Degtyarev [JB]]

Hello.
About the first one. Basically, it depends on the use-case. If this piece of code is going to be iOS-specific, there is no critical difference between these approaches. Workers are just more universal, as this concept is available for all native targets.
For the second question, it would be more correct to use a pool. There is no need to overextend the amount of the workers, as this gives no advance.

[Prateek Grover]

Thanks.

[Prateek Grover]

hey @Artyom Degtyarev [JB] I need some help regarding the worker pool creation. I am having trouble passing around worker pool object (Array of 5 workers) and workQueue object (MutableList) and keeping them mutable. Any pointers you can offer?

[Prateek Grover]

shall i share with you the initial code?

[Prateek Grover]

anything?

[olonho]

you shall use worker's queue, not mutable list, i.e. smth like

[olonho]

Untitled.kt

[Prateek Grover]

here, you are using worker's own queue to manage the job queue, what if I want to manage the job queue myself. then I would need a MutableList of work objects. isn't it?

I am trying to achieve something like this

[Prateek Grover]

Untitled.kt

[Prateek Grover]

there are some problems with this code. For example: after attaching workQueue and workers DetachedObjectGraphs, how do I reuse them?

[olonho]

what is exactly the problem you're trying to solve?

[Prateek Grover]

i am trying to create a worker pool to dispatch asynchronous requests to kotlin native framework made for handling business logic in iOS

[olonho]

then code above I quoted does the job

[Prateek Grover]

I get that. But it is suboptimal in the sense that if worker 1 is free but the index is at worker 7, we will still schedule the job on worker 7

[olonho]

so what prevents you from keeping track of worker load in an array of AtomicInt's and selecting target index smarter?

[Prateek Grover]

yes thats one way to optimize it but a better way would be to decide on the basis of how heavy the each load is by keeping track of free workers and maintaining a separate job queue

I think, what you mentioned should solve the problem.

[Prateek Grover]

but i still wonder how would we achieve what i was trying to do

[Kris Wong]

based on my understanding, you would need one thread to maintain the work queue, and you would need to send messages to it from other threads

[Kris Wong]

i would measure before adding such complexity

[Prateek Grover]

thats what i am doing using observerWorker. But the problem comes when I need to use executeAfter (that only takes frozen functions as param) which freezes the whole object graph after that including workQueue after which I can't mutate it

[Prateek Grover]

I agree to your comment regarding adding complexity

[Prateek Grover]

and if I do not use executeAfter, I will have to consume the future from execute which is a blocking call

[Kris Wong]

gotcha. i haven't looked at the details of this specific problem.

[Prateek Grover]

here is the code snippet that i am currently working with.

Untitled

[Prateek Grover]

if possible, can you have a look at it?

[kpgalligan]

To be clear, you’re doing this now to understand how it could be done, not because you need the complexity? You can avoid freezing graphs by keeping the actual intended executable visible to one thread, but again, not sure you’re going to get much practical use out of it.

[kpgalligan]

I took a look last night at the code you posted in the Kotlin native issue. Was kind of curious. I’m a little invested now.

[Prateek Grover]

yes, i think working with a separate jobQueue brings a lot of complexity. I will go with the solution suggested by Nikolay above.

thanks for your response kevin. did not really get what you meant by "keeping the actual intended executable visible to one thread" ...

[kpgalligan]

“But the problem comes when I need to use executeAfter (that only takes frozen functions as param) which freezes the whole object graph after that including workQueue after which I can’t mutate it” I don’t know the details of this, but in general if you need to pass around a function but don’t want to freeze it, as long as you can make sure the thread that eventually executes it was the thread that created it, there are ways to do this without actually freezing the function. However, since you’re not going down that route, it’s not a priority to get into the topic.

[Prateek Grover]

thanks kevin for your points. are you hinting towards casting function as a c pointer and then passing it into the worker for execution?

[Prateek Grover]

i understand i am not going to use this but still this knowledge would be quite helpful in future. KN looks very promising.