comsat

> Does that mean libraries need to be rewritten to support it? Yup. Here are the list of supported libraries [1]. > even concurrency strategies added late in a language's lifecycle Quasar code uses a regular Java Exception as a trick to stop execution and unmount, to sort of piggyback on the language features. Fibers do also implement the Thread interface; I think what you pointed at was indeed a concern of the author. I don't know how the Loom initiative look like. If you want to see how a library is adapted, here is JDBC [2]. [1] http://docs.paralleluniverse.co/comsat/#getting-started [2] https://github.com/puniverse/comsat/tree/master/comsat-jdbc/...

IMHO, I'm not sure if any of the above there besides the testing libraries is something that should be part of Kotlin, _especially_ if it hasn't even yet hit v1.0. That having been said, I think your concerns will be addressed, _eventually_, but JetBrain is not trying to disrupt Java or its ecosystem before mainstream adoption of the language. Re: async capabilities like Erlang/Go, until the JVM can support continuations, an industry standard solution like bytecode instrumentation, which Java9 will improve on, will entrench libraries like Quasar / RxKotlin to be basically drop in. These libraries provide seamless interoperability with existing synchronous libraries (see https://github.com/puniverse/comsat) to get around the fact that Erlang's/Go's async capabilities are not built-in to the language.

The short answer is that you can't just use any blocking code. The Comsat project (https://github.com/puniverse/comsat) contains integrations of popular libraries with Quasar fibers, without change to their API. Under the hood, this is done using transformations made available in the FiberAsync class. Like eitany said, you can use FiberAsync to integrate the library yourself, or wait for an integration module in Comsat. If library provides asynchronous APIs, it would yield great performance when integrated with Quasar fibers. If not (like JDBC), it would work as well as it does on regular threads, but won't interfere with all the other great stuff fibers can do.

Hi. You don't have to change the library in order to make it work through fibers. You have to wrap it. In case it has efficient implementation of the async-api you have to implement the fiber-synchronous using the asynchronous api. If it hasn't you have to wrap it with threadpool. You can take a look in the implementation of the JDBC wrapper here: https://github.com/puniverse/comsat/tree/master/comsat-jdbc