# About suspend functions that spawn coroutines that persist

**URL:** <https://discuss.kotlinlang.org/t/about-suspend-functions-that-spawn-coroutines-that-persist/23857>\
**Category:** Language Design\
**Created:** [January 6, 2022, 8:32pm UTC](https://discuss.kotlinlang.org/t/about-suspend-functions-that-spawn-coroutines-that-persist/23857 "2022-01-06T20:32:06Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![crg7475](https://avatars.discourse-cdn.com/v4/letter/c/4bbf92/32.png) [@crg7475](https://discuss.kotlinlang.org/u/crg7475)\
**Post date:** [January 6, 2022, 10:05pm UTC](https://discuss.kotlinlang.org/t/about-suspend-functions-that-spawn-coroutines-that-persist/23857/7 "2022-01-06T22:05:26Z")

</div>

Well that would be similar to `connectAsync` and then calling the returned Deferred’s `await()` function, right?

However, I do admit that passing a coroutinescope to a connect function for a keepalive coroutine still is a little weird as far as structural concurrency is concerned, since it may be confusing to the user to know just what scope they should pass to, what scope would make sense. So perhaps in this case it would then make sense to really set up a completely internal coroutinescope in the connect function, like this:

```auto
internalScopeMainJob = SupervisorJob()
internalScope = CoroutineScope(Dispatchers.Default + internalScopeMainJob)

```

Since the lifecycle of the keepalive coroutine would anyway be tied to the `connect` and `disconnect` calls, it would be straightforward to do this in `connect` and then call `internalScopeMainJob.cancelAndJoin` in `disconnect`. This would set up a separate coroutine hierarchy, but would be purely internal. Thoughts?

---

_[View the full topic](https://discuss.kotlinlang.org/t/about-suspend-functions-that-spawn-coroutines-that-persist/23857)._