All this talk of `--gc:arc` makes me a little bit frustrated, I feel like @andrea has a similar reaction. The fact is that I have so far seen no evidence that `--gc:arc` makes mixing concurrency and parallelism in Nim easier (I may very well be missing something, so please educate me with examples if so).
So yes, as things stand in Nim, you cannot easily mix parallelism and concurrency right now, but to me there is a fairly simple solution to this: we need to implement the ability to `await` a FlowVar (what `spawn` returns) and/or `channel.recv`. Either a member of the core dev team needs to be convinced to make this work or someone who's passionate about it needs to get it past the finish line (there were [some](https://github.com/nim-lang/Nim/pull/12232) [efforts](https://github.com/nim-lang/Nim/pull/12372) which made great progress, so I would say there is just a "little" push needed to get it to work). Of course, Nim's threading model is a little different than most languages. Threads are somewhat "heavy", with each having their own heap, so for use cases that require a lot of communication between threads you are better off not holding out hope for my suggestion above. There are alternatives, and I have been pretty successful in creating a very performant HTTP server for example: [https://github.com/dom96/httpbeast](https://github.com/dom96/httpbeast) (which this forum runs on). Now to answer some of your questions... > The asyncnet module documentation has a couple of caveats about Windows, like > "on Windows it only supports select()" and "In theory you should be able to > work with any of these layers interchangeably (as long as you only care about > non-Windows platforms)." I'm not clear on how this would impact clients, and > whether these caveats apply to using asyncnet or just the lower-level modules. We might need to rewrite that paragraph, but it is specifically only talking about the `selectors` module. We have a custom IOCP implementation in asyncdispatch which asyncnet uses. So you will get the greatest API support on Windows too. > The async examples I've seen run on a single thread. Is there any support for > distributing async calls across a thread pool? Not really. What you can achieve is something similar to what I created with httpbeast: each thread running its own Async event loop and allowing the system to load balance the socket connections. For clients that will likely be trickier. > The spawn function's thread safety seems to be based on segregating heap > objects per thread (Erlang-style.) This can involve a lot of copying, > especially when passing data buffers around. Is this something baked into the > language or is it specific to the spawn function? Are there alternatives to > this, like the more Rust-style model using move semantics? Yep, this is unavoidable right now. But I believe arc will indeed make move semantics possible, that's really the main advantage it will bring to threading in Nim. I could be wrong though.
