4 ms·

Greenlets ultimately have to be scheduled onto system threads at the end of the day unless you have a lightweight thread model of some sort supported by the OS,

Greenlets ultimately have to be scheduled onto system threads at the end of the day unless you have a lightweight thread model of some sort supported by the OS, so it’s a little bit misleading depending on how far down the stack you want to think about optimizing for greenlets. You could potentially have a poor implementation of task scheduling for some legacy compatibility reason, however. I guess I’d be curious about the specifics of what pron is discussing.

troupo 2y ago
Even though yes, in the end you have to map onto system threads, there are still quite a fee things you can do. But this is infeasible for Java, unfortunately. For example, in Erlang the entire VM is built around green threads with a huge amount of guarantees and mechanisms: https://news.ycombinator.com/item?id=40989995 https://news.ycombinator.com/item?id=40989995 When your entire system is optimized for green threads, the question of "it still needs to map onto OS threads" loses its significance
- binary132 2y ago
  I really don’t think it’s useful to be this nonspecific. You could give an example of what a Java greenlet cannot do or how it cannot be optimized, for example. If your whole point is actually just “I prefer the semantics of BEAM threads”, then just say that.
  - troupo 2y ago
    Those semantics are exactly what cannot be done in Java for many reasons (including legacy code etc.). And yes, those semantics are important, but sadly most people stop at "yay we have green threads now" and then a null pointer exception kills their entire app, or the thread that handles requests, or...
    - binary132 2y ago
      So let’s be clear, your point is that you find the API of non-BEAM greenlets less useful, not that they’re somehow necessarily less efficient. Right?
- MaxBarraclough 2y ago
  > When your entire system is optimized for green threads, the question of "it still needs to map onto OS threads" loses its significance How's that? What about parallelism?

troupo 2y ago

Even though yes, in the end you have to map onto system threads, there are still quite a fee things you can do. But this is infeasible for Java, unfortunately. For example, in Erlang the entire VM is built around green threads with a huge amount of guarantees and mechanisms: https://news.ycombinator.com/item?id=40989995 https://news.ycombinator.com/item?id=40989995 When your entire system is optimized for green threads, the question of "it still needs to map onto OS threads" loses its significance

binary132 2y ago
I really don’t think it’s useful to be this nonspecific. You could give an example of what a Java greenlet cannot do or how it cannot be optimized, for example. If your whole point is actually just “I prefer the semantics of BEAM threads”, then just say that.
- troupo 2y ago
  Those semantics are exactly what cannot be done in Java for many reasons (including legacy code etc.). And yes, those semantics are important, but sadly most people stop at "yay we have green threads now" and then a null pointer exception kills their entire app, or the thread that handles requests, or...
  - binary132 2y ago
    So let’s be clear, your point is that you find the API of non-BEAM greenlets less useful, not that they’re somehow necessarily less efficient. Right?
MaxBarraclough 2y ago
> When your entire system is optimized for green threads, the question of "it still needs to map onto OS threads" loses its significance How's that? What about parallelism?