5 ms·
Yep. 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 b
by cr__ 4y ago
Yep. 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.