for a progressbar for example?

It lets you do cooperative-multitasking. So, in

kotlinx.coroutines

there will be non-blocking sleep, so instead of writing code with callbacks you can just do:

asyncRun { 
   for (i in 10 downTo 0) { 
       myLabel.text = "Countdown $i"
       sleep(1000)
   }
}

And you're text label will count down from 10 to 0 every second. You can do animations with imperative code, too.

not in javafx!

that code will not work in javaFX

Progress communcation for compute intensive-code? Something like this:

asyncRun(myComputePool) { 
   while (true) { 
       // some heavy computation in compute thread pool
      asyncRun(JavaFx) { myLabel.text = "current progress is $x" } 
   }
}

So, basically

asyncRun(JavaFx) { ... }

is like a

Platform.runLater

you cannot access a Label from outside the javafx application thread

That is the whole point. by-default if you start

asyncRun

in application thread it stays in application thread by dispathing its continuations onto application thread with

Platform.runLater

we use the update methods of javaFX itself like

Wether it a good default for UI apps is a question I'm trying to figure out.

runAsync { updateTitle("Doing some work") for (i in 1..10) { updateMessage("Working $i...") if (i == 5) updateTitle("Dome something else") Thread.sleep(200) updateProgress(i.toLong(), 10) } }

You should not use

Thread.sleep(...)

inside a coroutine. We'll have an inspection to warn you.

Thread.sleep

is thread blocking. You'll use a non-blocking

suspend fun sleep(...)

the updateTitle and updateMessage from javafx itself check if they are on the right thread

that code is from the test case 🙂

The whole idea is that with coroutines you can have multiple async activities while staying in one thread. But you don't have to. You can have many threads, too (if you need for your compute-heavy stuff)

So, with `asyncRun`/`fork`/`go` (however we name it) this code presumably can change to something like

asyncRun {
                       title = "Doing some work"
                       for (i in 1..10) {
                           message = "Working $i..."
                           if (i == 5)
                               title = "Dome something else"
                           sleep(200) // you can also do all kinds of non-blocking IO here
                           progress = i.toLong()
                       }
                   }

but is the code inside the runAsync already running in a different thread?

The proper naming is a challenge.

runAsync

vs

asyncRun

is confusing... The Tornado's

runAsync

does start a new thread, but

runAsync

does not. It just creates a new coroutine in the same thread, cooperatively dispatching all computation onto it (at least, that is the planned default behavior)

for me that makes it confusing

That's exactly why I'm here.

when I read

asyncRun { code }

I will expect the

code

to be in async completely

Turns out that different people have different intuition on async. For some it just "some asynchronous activity", for others it implies a new thread. The later interpretation comes from Node.JS/JS world where there is always one thread and a lot of async, with every asyncSomething cooperatively working in the same thread....

I wonder how that will play with the javafx thread

Some, basically, one way to look and Kotlin coroutines is that it is bringing JS-style single-threaded asynchronity to JVM, but then the naming... that is the challenge...

a lot happens on that thread that we do not have influence over

In UI frameworks it is simple. JavaFx has

Platfrom.runLater(...)

, so for JavaFX I have

JavaFx

dispather. Every time coroutine resumes, this dispatcher does

Platfrom.runLater

with its continuation, so the rest of its code is back into application thread. Same for Swing and Android

you do

runLater

for each resume?

The coroutine framework delegates this decision to dispatcher that you started the coroutine with. So, if you start it with

JavaFx

dispatcher, the it does

Platform.runLater

. If you run it with

Swing

dispatcher, it does

SwingUtilities.invokeLater

and so on.

The trick in picking a default.

and each framework will get its own dispatcher