@machingan
> If it's in Windows, antivirus is to blame.
Oh! Do you think that anti-viruses don't check executable files created by
other compilers?
If so, then this is the conspiracy against Nim!
Anyway, I'll work on switching to `asyncnet`. I'm only just starting the
redesign just now
> Without async how are you planning to handle accepting connections and
> receiving messages from multiple clients?
I was going to use the `threadpool` module. That way I could have one thread
per client powered by a thread pool without the expense of creating new threads
one by one.
> Still, it can be harder to reason about async code, although the syntax is
> super easy (WAAAY better than the low level AIO stuff in C, or even MIO/Tokio
> in Rust).
Super happy to hear that
> As for performance, I wouldn't expect to see an increase, correct? The
> application would be
There isn't a real bottleneck - the performance is fine. I'm just not sure that
async would improve the performance _enough_. It is still an I /O bound
application. But it has little needed throughput. Only a couple clients usually
play at one time.
there also is
[https://nim-lang.org/docs/asyncfile.html](https://nim-lang.org/docs/asyncfile.html)
which allows basic async file operations and there is
That's a good point that I hadn't considered. One concern I have is that some
things have to be ordered. I was having some trouble with non-determinism of
the async dispatcher before. Likely it was user error
Still, it can be harder to reason about async code, although the syntax is
super
I would use asyncnet. But mainly for its compfort (not to say its not fast). It
allows to easily implement other "channels" such as a chat system or rpc in
general. Also long running procedure with asyncCheck that periodically sends
data every game tick or saves the map.
