Virtual/lightweight/green threads #323
Comments
|
The green thread space within C++ is quite immature, based on what I've seen. C++20 introduce rudimentary coroutine support, but it's more about providing legos for you to build your own coroutine. Some libraries have built around this, such as folly::coro. Others, like boost.asio fibers provide their own framework for this. I don't know if there are clear winners yet. Furthermore, there isn't a clear set of winners for actual async libs for doing various types of IO. From what I've seen, boost.asio likely is most popular here, but that's more because it's been around longer. For jank, we will choose an option, but ultimately this is low priority right now. We're still building out the core functionality of the language, solving packaging and distribution, etc. We may not tackle green threads for another year or more, unless someone else from the community drives it forward. |
|
I just wanted to document the issue without any expectation of timeline. If all else fails, we can still have core.async go blocks. |
Core.async go blocks are lightweight threads implemented as state machine. JVM virtual threads are supported by JVM. Have you thought about this?
JVM virtual threads haven't yet solved file I/O capturing and native pinning. File I/O capturing could be solved on linux with io_uring, but java developers decided to delay adoption of io_uring. Native pinning hasn't been solved yet because java developers think native pinning might be rare.
In core.async go blocks, parking operations don't cross function boundaries because state machines don't catch parking operations in functions called in go blocks. If you have virtual threads, blocking channel operations will park the virtual threads.
The text was updated successfully, but these errors were encountered: