Hacker News Reader

Comment by haddr | Hacker News Reader

Lightweight threads (fibers) looks especially interesting to me. I wonder if there is some library that already tries to ger around threads with something more lightweight...

View on HN

An interesting one is

http://docs.paralleluniverse.co/quasar/

They claim to have "true lightweight" threads. (I am sure pron if he is a around can jump in and expand on it).

It takes a lot from Erlang even pattern matching.

Well, the pattern matching is only in the Clojure API, but yeah, these are true fibers based on continuations implemented with bytecode instrumentation, scheduled by a work stealing scheduler (or any other scheduler of your choice). It lets you write simple blocking code with all its familiarity and advantages (exceptions, thread-local data) but enjoy the performance of async code.

The downside is that libraries have to be integrated in order to block gracefully when called on fibers, but we already have a long and growing list of integration modules for popular libraries.

Assuming this is not rhetorical; yes there is: http://www.paralleluniverse.co/quasar/

I would love to see threads based on this work (OS support for lightweight threads): http://www.linuxplumbersconf.org/2013/ocw//system/presentati...

It seems this would move most of the heavy lifting into the kernel (and out of the already-very-complicated JVM). Anyone know what happened to that work?

AFAIK, Google uses it (to some extent, at least), but the solution suffers some issues that make it less than ideal. While it relinquishes scheduling to the application, stack management remains the kernel responsibility, so while the task-switching overhead is greatly reduced, the threads are still not quite lightweight. The advantages to the approach is that it automatically crosses "language barriers", say, between the JVM and native code. This is very important for Google, who use C++ libraries as common code in their polyglot projects, but maybe not so important in other shops.

http://akka.io/

I love Akka, but I thought their implementation relies on regular JVM threads at the moment, isn't it? (I had a wishful thinking at first that they are using user-threads at first, but they are not like quasar or goroutines in any way from what I read, Actors might reuse threads and seem like a "lighter thread" but they are still using plain old JVM threads, for now at least)

Correct. Like goroutines, but even lighter, as they have no stack. Java threads map directly to OS threads, do they not?

I'm not sure I understand what distinction you are making. All of the examples you mention are built by reusing OS/JVM threads. That is how you have to implement user-threads. How do you feel Akka differs from Quasar/Go (aside from the coroutine/actor distinction) .

Quasar uses byte code instrumentation to do things you can't do with "regular" java. How exactly they can do things whne the JVM is the same JVM? good question, I don't know, I know implementing user threads simply means keeping stack information, keeping a scheduler, handling signals, without asking the kernel / OS for a native thread (had to implement user threads in C in the past, not fun)

Maybe the JVM allows for more fine grained control on PC location, and allows to "go to" different places in the code without invoking a native thread. But I know that when you create a Quasar co-routine / green thread / user thread / continuation or whatever we want to call it, then it's not the same as Akka.

In Akka, if you have a "conversation" between a million actors in a circle, you can still get 1 thread to be reused, if there is no need to use more than one. But if you try to do 3 things in 100% parallel, you might find yourself with 3 threads (from the little that I know).

In quasar, you can do all that, without invoking an OS thread, I think this is the main difference.

http://docs.paralleluniverse.co/quasar/

fj / jsr166 is in 7

sample code: http://docs.oracle.com/javase/tutorial/essential/concurrency...

Reply on news.ycombinator.com