4 ms·

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

by 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.

by apta 7y ago

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.