3 ms·
> think you have a wrong concept of what kotlin co-routines are and are assuming limitations that it simply does not have. What I’m referring to is this: > y
by Skinney 4y ago
> think you have a wrong concept of what kotlin co-routines are and are assuming limitations that it simply does not have.
What I’m referring to is this:
> you just use your connection pool as usual and use a threadpool based coroutine context to ensure you don't block your asynchronous request handling main thread.
For everything that is not coroutine compatible out of the box, you need to do something like what is described above.
When porting an existing application to coroutines, you also have to identify the places you need to introduce thread pool backed contexts and use them approprietly. You also need to setup these thread pools correctly so that you don’t end up using more threads than if you didn’t target coroutines.
For us, this extra complexity wasn’t worth it. If we were making an app from scratch and could choose coroutine friendly solutions for everything from the start, that would be different, but porting a legacy app to coroutines hasn’t been a good experience.
Fortunetly, project loom means all our current thread-based code will be just as scalable as coroutines in the not-to-distant future. That also means we can spawn more (virtual) threads and see a nice speed increase as well.
Btw, we’re already using kotlin for most code, just not coroutines.
- jillesvangurp 4y agoOK, I get you don't want to do the work to migrate an existing Java application. It's a lot of work. If you don't have a lot of problems with it right now, you could just leave the code as is. But just so you know, what you are describing is code that is currently boiler plate heavy in Java and essentially making it a lot simpler and easier to reason about with Kotlin. I think you are confusing problem and solution here. In any case, this is how you create a CoRoutineContext backed by a thread pool. val myContext = newFixedThreadPoolContext(100,"db-context") That's it. There's nothing else to do but "use it". There's no need to call shutDown. Or have some thingy to intercept uncaught exceptions. Or have a lot of boiler plate around using it. a simple launch(myContext) { ... } does the job.
- Skinney 4y agomost of our thread pools are long lived, so we don't ever shut them down. When the pool is not long lived, we have a try-with-resources wrapper which handles the shutdown. Most of the time, we do calls to .execute and then join the different threads at the end. The code running within the threads represent the majority of our code, so the boilerplate you're talking about might 10 out of 2000 lines. Our only problem is the number of threads we can spawn safely, and that limit is removed with loom.