We have our own Coroutines library which is based on JVM threads and queues as mailboxes between them.

There are two things to consider.

1) Scala has the akka library/feature. This is an alternative that might have advantages over using our own low-level mechanisms, just in terms of reducing lines of code. Akka's various features for multiplexing multiple actors across threads may or may not be advantageous when doing something as simple as co-routines.

2) There is now a scala coroutines library created as part of the storm project. This works entirely differently - doesn't create JVM threads. Instead it somehow gets code to use a separate stack data structure that is not the stack of a JVM thread. As of this date, I have no clue how this works other than it looks to be dependent on scala macros heavily.

We have a requirement that a coroutine can call a non-thread-safe library written in java for which one has only the jar. A callback from the library can resume another coroutine. Pretty sure Akka could do this, but I'm not sure about the storm coroutines library. How would it get the Java jar code to use its special stack?

But this is worth investigation anyway.