4 ms·
Eh... what exactly is "lightweight" about your threads? As far as I see you still use the same, standard JVM threads everyone uses, combined with a thread pool
by dubbledidu 13y ago
Eh... what exactly is "lightweight" about your threads?
As far as I see you still use the same, standard JVM threads everyone uses, combined with a thread pool.
What am I missing?
- pron 13y agoNo, these are true lightweight threads (implemented on top of an OS-thread pool, just as they are in Erlang and, I suppose, Haskell). You can have hundreds of thousands or even millions of these on a single machine. They can block for IO or for any other kind of synchronization (message passing etc.), just like regular threads.
- dons 13y agoAre they preemptive?
- pron 13y agoAbsolutely. Currently fibers (lightweight threads) may only be preempted when performing a blocking operation (IO or waiting on some synchronization mechanism). We will implement time-share based preemption if we see a need for that.
- VladRussian2 13y agowhenever i hear "lightweight threads" my PTSD from experience with Java "green threads" comes back. Of course, my rational mind understands that many years have passed and things may in other runtimes be implemented differently and there are many benefits vs. native, yet ...
- pron 13y agoThis has little, if any, to do with that. These lightweight threads are implemented pretty much exactly as they're implemented in Erlang or Go.
- piranha 13y agoThe fact that it's not using standard JVM threads? His blog post describes how everything works: http://blog.paralleluniverse.co/post/49445260575/quasar-pulsar http://blog.paralleluniverse.co/post/49445260575/quasar-puls...
- dubbledidu 13y agoThis blog post is extremely vague and handwavy. Looking into the actual source code didn't reveal anything “special” either, so I'll just call bullshit on these claims. Feel free to prove me wrong.
- pron 13y agoI don't know what you mean by "special" (nor do I understand which "claims" you have issue with), but these are true lightweight threads. We use runtime bytecode transformation to create continuation, so that we can suspend and later resume a call-stack. These continuations are then scheduled on a thread-pool. It works exactly like it does in any other lightweight thread implementation AFAIK, except that in languages such as Erlang or Haskell, these continuations are created by the compiler or by the runtime, while in Quasar they're created with bytecode transformation. The JVM doesn't support continuations out of the box, but its instrumentation mechanism allows you to implement them in a library. It isn't any more, or less, special than lightweight threads in Erlang or Haskell.