Question about the kotlinconf-app sample: The `Dat...

# ktor

[ctierney]

Question about the kotlinconf-app sample: The Database class is full of suspending functions (e.g. https://github.com/JetBrains/kotlinconf-app/blob/master/backend/src/org/jetbrains/kotlinconf/backend/database.kt#L42) that use a dedicated fixed threadpool context. I was wondering what the benefit of this style is? I would understand if the rest of the app called these functions using async or something, but as they are all just called synchronously I’m wondering if writing them as suspending functions does anything particular. (Also, as they are not called asynchronously---how does that fixed thread pool actually get used?)

[bdawg.io]

Let's say your application needed to insert a row and cannot do anything else until it does so. What would be the benefit of launching an async coroutine just to immediately await() on it? By using a suspending function, you are fulfilling a core design of coroutines that "concurrency must be explicit". async is only useful if you want to run multiple concurrent operations.

Using the fixed thread dispatcher puts a limit on the number of parallel queries executed on the database and by making the methods suspending via withContext, you can have more queries queue up for a turn than you have threads (workers that don't get a thread immediately will suspend until one becomes available)

[ctierney]

so when the suspending function is called, control gets handed to the new fixed thread dispatcher even though the calls are not async?

[ctierney]

(Definitely agree on the value of keeping concurrency explicit, I just wasn’t sure what else (aside from asynchronicity) using suspending functions enabled.)

[bdawg.io]

@ctierney that is correct. It’s very popular to use a separate pool of threads to perform blocking network/disk calls. So by using a separate fixed thread pool context, it allows your worker threads to be non-blocking and defer the blocking calls to specially allocated threads

[ctierney]

Thank you!