Mirror of forum.nim-lang.org

2192 :: reactor.nim 0.0.1 - an asynchronous networking library - is released

• zielmicha (orginal) [2016-04-09T01:18:14+02:00] view original

  I'm working on an alternative asynchronous library - reactor.nim. reactor.nim is an asynchronous networking engine for Nim. It's based on libuv and provides future-based API.

  reactor.nim doesn't use asynchronous mechanisms from asyncdispatch stdlib module and instead provides its own. They are arguably richer and more performant. The API is inspired by Dart and Midori OS. In particular, it's IO is centered around buffered stream, which allow most reads and writes to complete without any allocations (or "context-switches").

  You can grab it from https://github.com/zielmicha/reactor.nim or using Nimble. Relatively sparse documentation is hosted on https://networkos.net/nim/reactor.nim/doc/. Currently it works only on Linux and Mac OSX, but thanks to libuv porting it to Windows will be trivial.

---

• andrea (orginal) [2016-04-09T08:25:31+02:00] view original

  Wow, that looks great!

  I see there is a reactor/threading module. How does the event loop interact with threads?

  I am currently working on Rosencrantz, a DSL to write HTTP servers, which is currently based on the standard async packages, and as such is single threaded. Performance is not bad, but if Reactor allows to delegate the responding of requests on worker threads, I would be very much interested in porting Rosencrantz on top of it

---

• zielmicha (orginal) [2016-04-09T12:19:26+02:00] view original

  Currently, reactor/threading can only execute tasks that don't use event loop at all. When the task is finished, the result is deep-copied to main thread.

  Anyway, probably the best way to parallelize web servers is to spawn multiple processes and send socket file descriptors to them. There is some cross-platform support for that in reactor/ipc, but it needs polishing and more features.

---

• andrea (orginal) [2016-04-09T14:27:16+02:00] view original

  I tried two approaches with asyncdispatch, neither of which I was able to make work.

  1. I tried to complete the request on a different thread. The problem here is that asyncnet also contain a file descriptor but it is only a reference into a thread-local variable. On a different thread I cannot get the descriptor this way. I guess this is done because writing to those file descriptors is not thread-safe, and using locks would slow down the single threaded case. But really, I did not investigate much.
  2. So I tried to send the request data to a different thread using the channels module, compute the response there, and sending the response data back to the main thread along another channel, in order to complete the request there. Here the problem is that the main thread is stuck in the event loop and I could not find a way to make it wait for a channel at the same time.

  Do you think one of these approaches might work in some way with Reactor?

---

• zielmicha (orginal) [2016-04-09T16:19:44+02:00] view original

  This won't work with reactor.nim. Futures are allocated in thread local heaps.

  Something similar is implemented in reactor/threading - when processing is finished in the other thread, it notifies the main thread loop to resume execution (using uv_async_t).

---

• _tulayang (orginal) [2016-08-29T15:12:59+02:00] view original

  Good job. I didn't see TCP/UDP/HTTP Servers. Are you still developing them?

---

• zielmicha (orginal) [2016-08-29T15:23:40+02:00] view original

  Use createTcpServer from https://networkos.net/nim/reactor.nim/doc/api/reactor/tcp.html or newUdpSocket with bindAddress from https://networkos.net/nim/reactor.nim/doc/api/reactor/udp.html . There is still no support for HTTP servers.

---

• endragor (orginal) [2016-08-29T15:55:03+02:00] view original

  andrea,

  You could try to setup server sockets from multiple threads with SO_REUSEPORT|SO_REUSEADDR flags, instead of having single server socket in the main thread. That way, different threds may accept connections on the same address/port pair, while OS tries to evenly distribute load between them.

---

• Varriount (orginal) [2016-08-29T18:36:20+02:00] view original

  I would argue that the most performant networking model would use multiple threads, with each thread hosting its own asynchronous event loop. Multiple processes work as well, however you have the overhead that comes with complete process separation.

---