This might be a little off topic but I decided to give it a

Question

This might be a little off topic but I decided to give it a shot I m using a Kotlin Telegram bot framework from <https github com kotlin telegram bot kotlin telegram bot|here> Now the framework allows you to specify callback functions for certain actions For example if your Telegram bot receives a message you can tell the bot to respond to the message Here s the code ```fun main = runBlocking val bot = bot token = YOUR API KEY dispatch text launch println launched bot sendMessage ChatId fromId message chat id text = text bot startPolling ``` This code should set a callback for when the bot receives any text message from a user However the `launch ` never gets launched And I don t know why I know all this Telegram bot stuff might be off topic but it s related to coroutines and I can t comprehend why it wouldn t work Can somebody tell me what I m doing wrong

ephemient · Answer

scheduling is cooperative since `startPolling` is a blocking function no other coroutines in this thread can run until it returns

Martin Gaens · Answer

So the solution is to run `startPolling` in a coroutine

Martin Gaens · Answer

Putting the `startPolling` into a `launch ` block doesn t seem to help

Joffrey · Answer

This extra coroutine will still hold the only thread available because `runBlocking` holds the main thread and provides a scope that s an event loop on that thread If you pass a multithreaded dispatcher to it it should solve the problem

Martin Gaens · Answer

I ve been messing around with this for a while with no luck How exactly would I create a multithreaded dispatcher and then run the stuff using it

ephemient · Answer

`<http Dispatchers IO|Dispatchers IO>` `Dispatchers Default` are built in and on JVM you can create your own multi threaded `Executor` via the usual means and wrap it with ` asCoroutineDispatcher `

Martin Gaens · Answer

I should really dive deep into coroutines Very interesting I didn t know these two specifically were multithreaded Thank you very much I ll give it a shot

Martin Gaens · Answer

I s till can t figure it out confused nothing is working The bot gets run and after that no coroutines run anymore And as I checked they should be running on different threads I even tried to wrap the `bot startPolling ` inside a `thread start = true ` with no luck Here s the code ```fun log msg String = println $ Thread currentThread name $msg fun main = runBlocking val bot = bot token = XXX dispatch command sayHi launch <http Dispatchers IO|Dispatchers IO> log Hey bot sendMessage chatId = ChatId fromId message chat id text = Hi launch Dispatchers Default log Started polling bot startPolling Unit ``` Also are there any good resources for learning about coroutines Because when you google create multithreaded executor it doesn t bring up anything useful and easy to understand about creating multi threaded executors

uli · Answer

In your Original code pass a dispatcher to `launch` and see if that does the trick

Joffrey · Answer

gt If you pass a multithreaded dispatcher to it it should solve the problem < Martin Gaens> I meant to pass a dispatcher to `runBlocking` not to the `launch` directly The thing is because you run your top level code in `runBlocking` the thread is blocked while waiting for the second `launch` to finish even if the body of that `launch` is run on a different thread Everything needs to be multithreaded here not just the body of `launch`

Joffrey · Answer

Looking at your initial code again it doesn t seem right to use `runBlocking` at that level Everything is blocking here except your own coroutine call in `launch` By capturing `runBlocking` s scope in the callback s lambda instead of using `runBlocking` inside the callback you re possibly breaking invariants for this callback Maybe the framework expects you to finish doing your work in the callback before giving control back to the framework It also probably gives you a separate thread to do that but you re switching back to the thread held by `runBlocking` which is the main thread in this case

uli · Answer

From the sample on the framworks readme md it looks like all the framework code is supposed to run un the main thread or thread provided by framework for the callback and it is ok to do blocking work So your initial example looks correct except for the fact that you launch your coroutine on the main thread which is blocked Did you get to try launching the coroutine in the background And only putting the println inside the coroutine Could be that the framework is not thread safe and calling framework code from the background breaks things Btw why do you want coroutines any way It looks like it s fine to do all your work on the main thread or the one that your callback is called on ```fun main = runBlocking val bot = bot token = YOUR API KEY dispatch text println received Check if your callback is called at all launch <http Dispatchers IO|Dispatchers IO> println launched See if couroutine gets launched bot sendMessage ChatId fromId message chat id text = text Do not call framework from background thread bot startPolling ```

uli · Answer

i disclaim all that has been said and assert the contrary rolling on the floor laughing

uli · Answer

The issue is with `startPolling `is not blocking the main thread It schedules a run loop in a background thread and then returns immediately After that execution leaves runBlocking s scope This completes cancels the scope s job and prevents any new coroutines from being started StartPolling s run loop is probably scheduled on a non daemon thread which prevents the JVM from terminating after main exits So this should do the trick ```fun main cal scope = CoroutineScope SupervisorJob + Dispatchers Default val bot = bot token = YOUR API KEY dispatch text println received Check if your callback is called at all scope launch println launched See if couroutine gets launched bot sendMessage ChatId fromId message chat id text = text Do not call framework from background thread bot startPolling ```

Martin Gaens · Answer

gt In your Original code pass a dispatcher to `launch` and see if that does the trick The `` dispatcher is not working if I pass it into the original code gt I meant to pass a dispatcher to `runBlocking` Yeah I also tried that also not working < Joffrey> thanks for the answer you re right that the framework expects me to do all the work in the thread but I don t really like holding onto a thread when I m simply waiting for a Ktor response That s why I wanted to go full coroutine based But when the framework doesn t support coroutines I guess my only option to achieve this goal is to make my own stuck out tongue < uli> thanks for your detailed answers I tried doing a simple `println ` inside a coroutine with no luck The coroutine simply wasn t called at all Also the first thing you proposed didn t work The second one with the custom scope worked But it s still very annoying to me that the framework creates threads when coroutines are available to us in Kotlin and are preferable for doing simple network calls However why shouldn t I call the framework from a background thread coroutine

uli · Answer

If the framework does not state any thing about thread safety a conservative assumption is it is not thread safe That might be wrong and you might be just fine calling it from a coroutine thread My advise was mainly while you try to get it running to prevent any thread related issues The assumption was also based on the false assumption that the framework runs on the main thread An already mutli threaded framework is much more likely to be thread safe Now that it runs feel free to try calling the bot from your own threads

uli · Answer

The framework itself not using coroutines seems more like an implementation detail Why would you care You can still use coroutines for your purpose And coroutines would become important if the framework had to serve thousands of connections My assumption is this is not the case here

Martin Gaens · Answer

Yeah I ve seen a few ` Volatile`s spread out in the framework so I m guessing we can assume it is thread safe And yeah I guess the thread implementation detail is a small detail but I think it s still much better using coroutines because I m planning on deploying on not so good hardware where there s a very limited amount of threads available

gildor · Answer

I honestly don t see why you need runBlocking here at all just create your own scope application level or and request level or even use GlobalScope and run coroutine And what is your goal here To use coroutines to run multiple tasks in parallel

gildor · Answer

Answering your original question directly just remove runBlocking replace launch with GlobalScope launch But the actual solution depends on what kind of lifecycle you expect from your coroutines