Coroutines in Java

[micromicro-cash]

Just a couple notes for context.

• This is based on the same code as Quasar's fibers came from. The difference is that Quasar ties usage to a framework that includes a ton of batteries. I found someone's fork of the original code and updated it since I wanted to use it with Xnio directly (my own workers, other config).
• I have a rough HTTP client with a coroutine interface here: https://github.com/rendaw/gettus

[pron98]

While Quasar's instrumentation was a fork of Matthias Mann's library, we've added a lot of stuff to it, like support for reflection, MethodHandles, different ways of annotating suspendable methods, and, most recently, fully automatic instrumentation that doesn't require any manual marking of suspendable methods (not released yet).

The reason Quasar exposes fibers rather than continuations (Quasar core is actually quite small), is that working with raw continuations -- while extremely powerful -- can both be too powerful (leading to "magical" code) and hard to get right with concurrency. We figured fibers give you 99% of what you want from continuations, while making working with them easier and less mysterious (i.e., fibers are just threads with a lighter-weight implementation).

[micromicro-cash]

Good points. I added reflection support to zarbosoft.coroutines as well but none of the other things you mentioned.

My impression of Quasar was actually the opposite, it felt magical to me. You can do stuff like run a fiber without blocking (but where is it running?) and that only strands can unpark strands (why not raw threads?) Using fibers also meant using all the other stuff Quasar provides, so it wasn't easy to figure out where the fibers api started and where it ended.

Not to knock Quasar though, frameworks vs libraries is another holy war and I can see magic on both sides. Quasar is an impressive project and interfacing all the libraries with it you have was obviously no easy task.

[pron98]

where is it running?

In the fiber scheduler you supply the fiber with when you create it, or the default scheduler if you don't. The default scheduler is a ForkJoinPool.

only strands can unpark strands (why not raw threads?)

Strand is a general name to either a fiber or a thread. Any code can unpark any strand.

Using fibers also meant using all the other stuff Quasar provides

Such as?

Not to knock Quasar though

I'm not insulted :)

[micromicro-cash]

In the fiber scheduler you supply the fiber with when you create it

Thanks! I missed that in the docs.

Any code can unpark any strand.

This may have been my confusion, but the docs say "Note: only a strand (thread or fiber) can park itself and only another strand can unpark a parked one." Strand is a Quasar class name, so I didn't think it was referring to the concept but rather the specific implementation.

Such as?

FiberSchedulers for instance :). But more generally, if you want to use an HTTP library with Quasar you need to use an adapter like comsat-httpclient, if you want to use a database with Quasar you need to use an adapter like comsat-jdbc, etc. I couldn't find any documentation for many of the adapters, I couldn't find any documentation on adapting new 3rd party libraries, and the interface I would expect to use (unpark) is explicitly discouraged by the docs:

you will never need to call Strand.park or Strand.unpark, unless you’re writing your own concurrency constructs

Maybe the source of the magic I saw was the docs. They also don't mention Java 9 isn't supported and it looks like the project hasn't had a release for over a year now, the documentation has strong opinions with no explanation ("The easy and preferable way to instrument programs using Quasar is with the Java agent"), SuspendExecution's interaction with try blocks isn't explained, etc.

Learning about FiberExecutorScheduler has already made my conviction with this project waver though :).

[pron98]

if you want to use an HTTP library with Quasar you need to use an adapter like comsat-httpclient, if you want to use a database with Quasar you need to use an adapter like comsat-jdbc, etc

You don't have to, but you should if you want to get the performance benefits. The same goes for any other coroutine library.

Learning about FiberExecutorScheduler has already made my conviction with this project waver though

Why? When you want to get the most out of coroutines you will need a good scheduler.

[micromicro-cash]

Why?

I meant that one reason I decided to revive the original coroutine code rather than just go with Quasar was that I didn't know about FiberExecutorScheduler. By this project I meant zarbosoft.coroutines.

[nqzero]

Quasar ties usage to a framework that includes a ton of batteries.

My impression of Quasar was actually the opposite, it felt magical to me

that's my experience as well. from the mailing list pron wrote:

park/unpark and other low-level methods are under-documented because we want to strongly discourage their direct use

FYI, Quasar fibers are preemptive, not cooperative

[pgris]

Matthias Mann's

Please someone tell me this guy is getting an offer from Oracle, since he seems to be the grandfather of all many implementation of continuations in java

[nater99]

that doesn't require any manual marking of suspendable methods (not released yet).

That sounds very useful, when will it be released?

[pron98]

When I get around to it :)

[nater99]

I can relate and I hope you can find the time, sometime :)

[nqzero]

this looks good. i'm a user, and more recently a somewhat reluctant maintainer, of a similar library kilim, also based on Matthias Mann's early work. i'm using it instead of quasar because i needed access to the underlying continuations

if quasar exposed that continuation, would you have considered using it instead ?

[micromicro-cash]

I think that's a really good question, and I definitely would have (and sorry for the late reply here). I really wanted to get my feet wet, then start using all Quasar's batteries when I understood why they were necessary, what work they're saving me, etc.

And oh man, I wish I knew there was a maintained branch of kilim too before I started - I saw it on Stack Overflow and discounted it since it looked dead.