It is not androind-only, though. It is just a bad code due to inlining (does not verify on JVM, too)

If you remove

inline

from

runOnThread

it works just fine

@Paul Woitaschek Thanks a lot for finding and reporting it!

gerne 🙂

Hi, excited to see coroutines in kotlin. I want to use them for connecting with RDBMS (mysql/postgres)

But as I understand, it would block the thread

is there any way to do async programming with RDBMS

I checked out postgresql-async (https://github.com/mauricio/postgresql-async/)

Thanks

@geekasm It would be great is somebody ports async sql driver for Postresql to Kotlin. Meanwhile, you need to follow these steps: 1. Decide how many concurrent SQL operations you’d like to have at max (let’s call it

n

). 2. Define your own context for SQL operations like this:

val SQL = newFixedThreadPoolContext(n, "SQL")

3. Wrap your SQL operations into

run(SQL) { ... }

invocation. It works best if you ecapsulate them in suspending functions like this:

suspend fun mySqlOperation(params) = run(SQL) { .... }

Now you can use those suspending functions from coroutines and it will not block anything.

Ok, Thanks @elizarov

Funny, usually lambdas that are not

suspend

that contain a suspendable function usually complain that you can't run a suspendable function there, in

measureTimeMillis { }

lambda, no complaint...!?

probably because inline

Oh, you're right, thanks!! That could be helpful to know!

A pity, it looks like we can't use Mockito param matchers with a suspend function:

org.mockito.exceptions.misusing.InvalidUseOfMatchersException: 
Invalid use of argument matchers!
2 matchers expected, 1 recorded:
-> at com.....SyncServiceSpec$1$3$2$5$1.doResume(SyncServiceSpec.kt:162)

This exception may occur if matchers are combined with raw values:
    //incorrect:
    someMethod(anyObject(), "raw String");
When using matchers, all arguments have to be provided by matchers.
For example:
    //correct:
    someMethod(anyObject(), eq("String by matcher"));

Since Mockito expects that all params should use matchers,

and the suspend function injects a continuation...

Is Java Loom equivalent to Quasars or Coroutines ? http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html

@dave08 Have you updated to the latest version of Mockito?

@janvladimirmostert Project Loom is designed to solve the same problems that Quasar and Kotlin Coroutines solve (async programming, many many light-weight tasks), but how exactly it is all going to work out is too early to tell.

ok, good to know that they are thinking about it, lightweight threads is something that’s been missing form the JVM for ages.

@janvladimirmostert They’ve hired Quasar’s author (Ron Pressler), so we can expect that it is going to be designed around the Quasar concepts (for example, Ron likes the terms “Fiber” and “delimited continuation” and uses them all the time), but the implementation is going to be vastly different, for sure, since it is going to be part of JVM.

@dave08 Try mockito 2.8.47 (or later)

@elizarov awesome! Ron is an expert on the topic, so looking forward to see it built-in to the JVM

@janvladimirmostert I would not be very hopeful to see it released in a foreseeable future. It is a huge engineering challenge to get an all-encompassing thing like coroutines integrated into JVM. They’ve set the bar very high with respect to their goals.

@elizarov Timeline will probably be 5 years, will continue using Co-routines in the meantime

I think the main practical problem with what's been proposed for Fibers is that there is a fundamental limit on how small overhead suspension/resumption can be and how often it happens. For example, given a bounded "blocking" queue, either 1) the producer is faster and gets always suspended on the queue becoming full -> then resumed when at least one slot opens up; or 2) the consumer is faster and gets suspended when the queue is empty -> then resumed when an item becomes available. Both cases will effectively incur the extra overhead per item. I think, for coroutines, suspension involves allocating a holder object for the remainder of the coroutine's code and then performing 1 or 2 atomic operations so the (potentially asynchronous) resume() call can find it. For Fibers, this can be more costly because there will be likely a mandatory task scheduled on the ForkJoinPool all the time which by itself adds wrappers and atomics due the internal workstealing-enabled queue. In contrast, one can think about the async boundary in a Reactive-Streams flow as a batch-suspend and batch-resume, thus the unavoidable task scheduling overhead may be distributed along multiple items produced and consumed. In addition, its cooperative nature means the producers only produce as much as the consumer requested and stop themselves, returning from the depths up to the current thread pool's worker thread which continues with the next task. No stack state has to be preserved but only a handful of operator-specific state information has to be saved to an existing instance most of the time.

📣 📣 📣

kotlinx.coroutines

version 0.19 is released. It is now published to Maven Central.

DefaultDispatcher

is introduced, so

launch { ... }

and

async { ... }

can be used w/o parameters. Parent coroutines now wait for their children. The full list of changes in here: https://github.com/Kotlin/kotlinx.coroutines/blob/master/CHANGES.md

is there a way to set the default?