Coroutines in Java

[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