I am authoring a library “SDK” in Kotlin which wraps a c++ core. I would like to avoid launching Coroutines as much as possible, though I am not quite sure why this is important to me. I’d like to examine this feeling and get some perspective.
Clearly, I would spin up a thread if needed in Java as part of an analogous SDK, but in Kotlin it seems that I should design around asking the user to pass in a CoroutineScope, or even make extension functions on CoroutineScope, to make clear something will be launched in the background. These options do not seem appropriate for every situation. Extending
CoroutineScope as part of our SDK seems risky from a namespace perspective. And with passing in a
CoroutineScope, for example, to obtain a
shareIn(CoroutineScope), I am hesitant to obtain the scope through some constructor parameter or mutable property, and definitely not through a method parameter as this would upset the callback cold flow. I am also aware of
SharedFlow.tryEmit but I’d like to guarantee the delivery of all values to all collectors.
So I am wondering if I am misreading the principles of structured concurrency. Perhaps it is fine to use the default dispatcher to launch such work as calling emit on a SharedFlow in a library.