Re: collections.nim and reactor.nim v0.3.0 released

2017-04-21 Thread zielmicha
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 cases when kernel TCP support is too slow.

0.5.0 will hopefully use the same Future implementation as stdlib (and maybe 
more).


Re: collections.nim and reactor.nim v0.3.0 released

2017-01-11 Thread zielmicha
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 thing you and Araq would accept rewriting asyncdispatch to use libuv 
and dramatically changing the API of asyncdispatch/asyncnet. Future and 
Input/Output objects are incompatible with stdlib for good reasons - for 
example, using my abstractions, it's possible to:

  * efficiently implement `readLine` without using internals of socket object
  * do async calls without allocations in a more elegant way than `FutureVar`
  * write SSL/TLS support module without inlining it into module that supports 
sockets (!)



To avoid the situation you described, I'm planning to write drop-in 
asyncdispatch/asyncnet replacement that will use reactor.nim loop. In the long 
run, I think the way to go is to define portable API for event loops (in a same 
way [Python 
does](https://docs.python.org/3/library/asyncio-eventloop.html#asyncio-event-loop)).
 This way, different async libraries could be bridged together.


Re: collections.nim and reactor.nim v0.3.0 released

2017-01-11 Thread _tulayang
@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.} =
  await sleepAsync(1000)
  while true:
var chunk = await req.readStream.recv()
if chunk == "":
  break
echo "recv a chunk: " & chunk

server.on("clientError", handleError)
server.on("request", handleRequest)



Re: collections.nim and reactor.nim v0.3.0 released

2017-01-11 Thread dom96
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 future 
project foobar. What can we do to avoid this?


Re: collections.nim and reactor.nim v0.3.0 released

2017-01-11 Thread andrea
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


Re: collections.nim and reactor.nim v0.3.0 released

2017-01-11 Thread zielmicha
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/threading.html)](https://networkos.net/nim/reactor.nim/doc/api/reactor/threading.html\)).
 I'm planning for quite a long time to add multithreaded HTTP server to 
reactor.nim, libuv already supports passing sockets between threads. 


Re: collections.nim and reactor.nim v0.3.0 released

2017-01-11 Thread andrea
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 build an actually multithreaded 
http server on top of reactor? (with different threads servicing different 
connections, each of them async)?


collections.nim and reactor.nim v0.3.0 released

2017-01-10 Thread zielmicha
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](https://networkos.net/nim/reactor.nim/doc/tutorial.html), [API 
docs](https://networkos.net/nim/reactor.nim/doc/)).

collections.nim is a collection of several mostly independent module 
([Github](https://github.com/zielmicha/collections.nim), [API 
docs](https://networkos.net/nim/collections.nim/doc/)). Notably, is has 
[weakref](https://networkos.net/nim/collections.nim/doc/api/collections/weakref.html)
 module that implements weak references and 
[pprint](https://networkos.net/nim/collections.nim/doc/api/collections/pprint.html)
 which is a more readable alternative to built-in repr.