Wrote up a (longish) question on StackOverflow abo...
# kotlin-native
j
Wrote up a (longish) question on StackOverflow about DetachedObjectGraph (keeping a resource open in a separate thread and sending messages to it), if anyone is inclined to take a peek: -->
d
I'll have a go
j
Thanks! Hmm, I'm not totally following. Can you elaborate on how you'd use the atomicref? When would the atomic ref change? Also, if I froze the Logger, then I could just pass that into the worker. The point of DOG in my implementation was to keep the Logger mutable ( in my case e.g to close the file in the end, but the logging+file is really just an example).
d
I'm basically saying you should hide the mutability inside the class.
The atomic ref would change everytime you attach the
DetachedObjectGraph
, since you'll have to create a new one.
j
i see. so with each call to "log", I'd attach it, log, and then create a new DOG, and set it as the ref
hiding the mutability: yeah that makes sense.
I still wonder what a good usecase for DetachedObjectGraph is. Probably more longer running worker jobs ... Anyways. I guess I was looking for some nice API like a Worker where one can pass in a mutable state. Or something with a constructor where a mutable object could be created. Seems like the idea is that Worker + private vars tagged as ThreadLocal is all we need, and these "nasty" implementation details can/should just be hidden away.
My experience as someone who's not terribly experienced with concurrency / native dev was quite confusing. I think the problem was that I expected APIs to exist that would handle situations like this in a way that feels less hacky.
Thx @kpgalligan for your response! Have a little follow up for you on SO.
k
Updated
I’m working on something like this for Stately, but with the new coroutines rather than Worker directly (but could be with Worker)
j
Thanks for sharing your solution!