4 ms·
Yes. But, since there are _two_ kinds of threads in Java (os and virtual), you still have to be very careful never to block a virtual thread. In Go/JavaScript/B
by pkulak 5y ago
Yes. But, since there are _two_ kinds of threads in Java (os and virtual), you still have to be very careful never to block a virtual thread. In Go/JavaScript/Beam, it doesn't matter because you literally can't block a thread (while idle). This is the kind of thing that's not terribly useful until nearly every library you interact with is using it as well.
Also, there's no new syntax, so you're stuck with all the same thread pool concurrency we've been using for decades.
EDIT: It looks like I'm wrong about this:
> My understanding is that you won't have to worry about blocking a virtual thread, because all IO APIs are being modified to park when executed in the context of a virtual thread.
- foota 5y agoIf it's added to the VM then won't that allow languages like Kotlin to add support?
- vips7L 5y agoKotlin coroutines could take advantage of virtual threads but they still will have the syntatic problem of colored functions.
- Skinney 5y agoKotlin can call regular Java APIs, though. Doesn't have to take the coroutine route.
- vips7L 5y agoYes but then your code isn’t idiomatic/multi platform/whatever. It’s a trade off (and one where I would always chose Java).
- pjmlp 5y agoI learned an hard lesson in the Borland ecosystem. Always go with the platforms languages, and the IDEs from the platform owners, even if others are more shinny. Long term it always pays off to be the turtle, as the platforms move into directions not forseen by the shinny objects, and 3rd party IDEs keep playing catching up with SDK features.
- pkulak 5y agoWhat if the company that makes Kotlin is the one that makes the Java IDE?
- Twisol 5y agoEclipse and NetBeans do exist, and... ehhhhh. I used NetBeans for a long time; couldn't stand Eclipse; and these days I only use IntelliJ. But the others absolutely exist, and it'd be hard to say that Apache and the Eclipse Foundation aren't deeply embedded in the Java ecosystem.
- vips7L 5y agoEclipse is fine. Especially from VsCode where it uses the Eclipse language server. It boots fast, and when you run it with a modern JVM and GC the memory usage is leagues lower than IntelliJ.
- Twisol 5y ago> Especially from VsCode where it uses the Eclipse language server. Sure, but my particular complaint isn't with the functionality; it's with the UI. Yes, VS Code absolutely improves the experience.
- tadfisher 5y agoEclipse tried their own language: https://www.eclipse.org/xtend/ https://www.eclipse.org/xtend/
- pjmlp 5y agoThey make one Java IDE, zero contributions to the JVM, and are all cozy with "screw you Java devs" Google godfather. IBM does Java and the IDE (Eclipse). Red-Hat and Microsoft do Java and the IDE (VSCode).
- native_samples 5y ago
- Skinney 5y agoIf you need multi-platform then coroutines is still your best bet. But many people don't use Kotlin in a multi-platform way, and lightweight threads will be an easier migration path (and more compatible with Java libraries if you cant avoid one) compared to coroutines.
- pjmlp 5y agoIn abstract, yes. In the real Kotlin world of taking a random Kotlin library and call it from Java, most likely "it depends".
- Skinney 5y agoI didn't mention calling Java from Kotlin. Kotlin can call a Java API to spawn a lightweight thread. There's no reason to use coroutines when you can do that.
- pjmlp 5y agoOnly if the Kotlin code is to be tied to the JVM, if you want that Kotlin library to be usable on Android, that isn't an option.
- Skinney 5y agoYes, which is perhaps the best part about virtual threads. Java, Kotlin, Scala, Clojure, Gradle... everyone benefits.
- pjmlp 5y agoGuest languages always have to deal with taking decisions that don't go along with the platforms, regardless how they boost being "better".
- didibus 5y agoMy understanding is that you won't have to worry about blocking a virtual thread, because all IO APIs are being modified to park when executed in the context of a virtual thread. That said, you'd still need to worry about unsafe code, like JNA/JNI or other such thing that could still block. And I'm not sure there will be a way to prevent long running CPU task from clogging up the virtual thread executor threads.
- Twisol 5y ago> My understanding is that you won't have to worry about blocking a virtual thread, because all IO APIs are being modified to park when executed in the context of a virtual thread. And, from what I read in the original JEP, the underlying system thread pool (which all virtual threads float between as needed) will be expanded when a virtual thread gets pinned, so you don't have to worry about exhausting your pool. (If you pin too many threads, obviously you'll be consuming more OS resources than you may have expected, but that's a different problem.)
- didibus 5y agoWhat do you mean by pin here? Do you mean that a blocking IO will block the thread, but it will also add one more thread to the virtual thread executor pool? So blocking won't starve your virtual threads?
- Twisol 5y agoThat's right. From the linked JEP, under "Scheduler": > Some blocking APIs temporarily pin the carrier thread, e.g.most file I/O operations. The implementations of these APIs will compensate for the pinning by temporarily expanding parallelism by means of the ForkJoinPool "managed blocker" mechanism. Consequentially, the number of carrier threads may temporarily exceed the number of available processors.
- hn_throwaway_99 5y agoJust to clarify, though, most currently blocking IO operations will not pin the carrier thread, because most IO operations you make from a webserver are network calls (e.g. to another API or the database), and those network APIs have been modified to not pin. From just a bit further up in the JEP: > The implementation of the networking APIs defined in the java.net and java.nio.channels API packages have been updated to work with virtual threads. An operation that blocks, e.g. establishing a network connection or reading from a socket, will release the underlying carrier thread to do other work.
- _0w8t 5y agoIn Go one can block the native thread via using API that use blocking OS calls, like Linux file IO. In this case Go runtime allocates more native threads to run other language threads.
- SureshG 5y agoThat's case for virtual threads also. It uses ForkJoinPool.ManagedBlocker to add additional threads. "File I/O is problematic. Internally, the JDK uses buffered I/O for files, which always reports available bytes even when a read will block. On Linux, we plan to use io_uring for asynchronous file I/O, and in the meantime we’re using the ForkJoinPool.ManagedBlocker mechanism to smooth over blocking file I/O operations by adding more OS threads to the worker pool when a worker is blocked."
- kaba0 5y agoAnd you are incorrect on the other point as well: https://openjdk.java.net/jeps/8277129 https://openjdk.java.net/jeps/8277129 :D