5 ms·
When JVM lands support for virtual threads, what reasons remain for using core.async? core.async will still be useful in ClojureScript land, though.
by Skinney 4y ago
When JVM lands support for virtual threads, what reasons remain for using core.async?
core.async will still be useful in ClojureScript land, though.
- dgb23 4y agoChannels & alts etc. are useful constructs regardless right?
- Skinney 4y agoSure, but do these have API's that work with regular threads?
- cr__ 4y agoYep. They’re decoupled completely from the “go” bits in core.async that are meant to make up for the lack of green threads. All of the channel operations have blocking variants that work fine with regular threads now, and they seem likely to work fine with fibers.
- Skinney 4y agoDidn't know that, that's great!
- pgt 4y agoDoes that mean we can use core.async channels without the `go` macro? How would this look?
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- bcrosby95 4y agoI don't know if you mean something deeper, but core.async has <!, >!, and alts! variants that don't require a go block: <!!, >!!, and alts!!. You can just use them like a function. But they block the thread. So if you e.g. naively call it in the REPL you will block it indefinitely. E.g.: (>!! (chan) "this will block the REPL") The idea would be to pass a channel to multiple virtual threads which use the blocking versions.
- didibus 4y agoYes you can. Core.async already supports using normal threads with the `thread` macro instead of using the `go` macro. All code looks exactly the same otherwise.