3 ms·

"Getting" and "built with" are entirely different beasts. In Java, if it gets first class green threads...does all code immediately start using those instead o

"Getting" and "built with" are entirely different beasts. In Java, if it gets first class green threads...does all code immediately start using those instead of an actual thread pool? Probably not; your runtime behaviors would change. Will all libraries immediately change to using them? Assuredly not, again, runtime behaviors will change, and no matter how cleanly implemented, switching and testing will take effort, for both the library maintainer and the consumer. As a consumer, then, you're left with a moving target as some of your underlying libraries make the switch, plus the related testing effort. And you also have to either make a clean switch over, or you have to mix threaded + greenthreaded libraries, which is likely non-trivial. Languages that offer a single, sufficiently powerful concurrency construct avoid that; all golang libraries support goroutines (even if they are not themselves leveraging them).

apta 7y ago
I'm not sure what you're referring to. The JVM itself will support green threads, which means that any existing blocking libraries can be called from said green threads and they will become asynchronous. The runtime will take care of multiplexing the green threads on hardware threads when an IO operation takes place for instance. It's pretty much transparent to the user.
- lostcolony 7y ago
  >> any existing blocking libraries can be called from said green threads and they will become asynchronous Yes, but any frameworks that currently create and manage a threadpool will not automatically be changed. As well as any libraries/frameworks that rely on async code. And any existing code you own will also not. For brand new projects, using only libraries that assumed blocking code, and had no threadpool expectations within them, sure, it's transparent. For any old projects it's not. For any libraries that were written to be async already, you don't benefit. For libraries written to manage a threadpool, you have to wait for them to be updated. And still, as now, God help you if you want to mix and match, to use a library written to be async, and a library written to use a threadpool...but of course, now compounded because you want to write sane, performant, readable blocking code using green threads. You have to deal with all those incongruities and make them all work together. Languages that have an M:N threading mechanism from the get go (hah!) get the benefit of everything building atop that from the beginning.
  - apta 7y ago
    From my understanding, they're making the green thread API be very close to the current threading API, so that you need minimal changes to make them work. If I'm not mistaken, if you're already using an Executor, it's just a matter of passing one or two extra parameters when constructing it to make everything seamlessly use green threads. Even with mixing and matching, current systems can already run thousands of hardware threads, so I'm not sure it will affect performance or debuggability in any major way.

apta 7y ago

I'm not sure what you're referring to. The JVM itself will support green threads, which means that any existing blocking libraries can be called from said green threads and they will become asynchronous. The runtime will take care of multiplexing the green threads on hardware threads when an IO operation takes place for instance. It's pretty much transparent to the user.

lostcolony 7y ago
>> any existing blocking libraries can be called from said green threads and they will become asynchronous Yes, but any frameworks that currently create and manage a threadpool will not automatically be changed. As well as any libraries/frameworks that rely on async code. And any existing code you own will also not. For brand new projects, using only libraries that assumed blocking code, and had no threadpool expectations within them, sure, it's transparent. For any old projects it's not. For any libraries that were written to be async already, you don't benefit. For libraries written to manage a threadpool, you have to wait for them to be updated. And still, as now, God help you if you want to mix and match, to use a library written to be async, and a library written to use a threadpool...but of course, now compounded because you want to write sane, performant, readable blocking code using green threads. You have to deal with all those incongruities and make them all work together. Languages that have an M:N threading mechanism from the get go (hah!) get the benefit of everything building atop that from the beginning.
- apta 7y ago
  From my understanding, they're making the green thread API be very close to the current threading API, so that you need minimal changes to make them work. If I'm not mistaken, if you're already using an Executor, it's just a matter of passing one or two extra parameters when constructing it to make everything seamlessly use green threads. Even with mixing and matching, current systems can already run thousands of hardware threads, so I'm not sure it will affect performance or debuggability in any major way.