I've just released version 0.4.0 of reactor.nim. It contains substantial
performance improvements and multicore support (i.e. running multiple threads,
each with its own event loop, possibly communicating).
There is also very very basic support for MTCP/DPKD userspace networking stack,
for the
@dom96
By the way, I think event-driven models are useful for plug-in programming. How
about adding events to asyncdispath and asynchttpserver? Such as :
proc handleError() {.async.} =
await sleepAsync(1000)
echo "handleError"
proc handleRequest(req) {.async.} =
I started this project with the following assumptions:
* use libuv (or something similar) to avoid having to support code for every
platform (this is really important, I don't want to test everything on >3
platforms even when making small changes)
* have API as clean as possible.
I don't
I really appreciate your efforts but I must ask, why did you decide to write a
new library instead of helping improve the standard lib async modules?
My fear is that we will end up with 30% of libraries supporting reactor.nim,
40% of libraries supporting stdlib async and 30% supporting async fut
Thank you! Right now
[Rosencrantz](https://github.com/andreaferretti/rosencrantz) is based on the
stdlib HTTP server, but I have been wanting to base it on something
multithreaded for a while
There is no direct compatiblity with standard async, but porting code from
stdlib should be easy (many features have similar syntax).
Currently there is support for running tasks in a thread pool, but the tasks
can't use event loop at all
([https://networkos.net/nim/reactor.nim/doc/api/reactor/
Does reactor support any kind of compatibility with the standard async?
In particular, there is the module `asynchttpserver`: how hard would it be to
port it to reactor?
As a second question: what, if any, is the interaction between reactor event
loop and threading? Would it be possible to buil
I looked into your collections library, and I saw your View library. I have my
own implementation of the same thing
[here](https://github.com/krux02/opengl-sandbox/blob/master/glwrapper.nim#L8).
Maybe it has minor differences, but generally it is the same thing. `openArray`
in parameters also s
I have just released version 0.3.0 of collections.nim and reactor.nim libraries!
reactor.nim is an alternative asynchronous networking engine for Nim based on
libuv. The main addition in this release is much improved documentation
([Github](https://github.com/zielmicha/reactor.nim),
[tutorial](
