6 ms·

So it looks like libuv could use libdill, right?

• beagle3 9y ago
  Could have, possibly, but makes no sense at all to retrofit libuv with libdill at this point
  • piscisaureus 9y ago
    Shameless(-ish) plug: https://github.com/piscisaureus/wepoll https://github.com/piscisaureus/wepoll is not a fat abstraction layer but it could help with windows support.
    • beagle3 9y ago
      Libuv supports windows and in some ways only exists because windows support is needed; on Unix/Linux where Node started, libev was sufficient; libuv was created to facilitate the windows port of node - though it is now standing in its own right.
      • piscisaureus 9y ago
        I know - I am one of the authors of libuv. However libuv is pretty big and imposes its own asynchronous i/o model onto your application. Later I discovered that it is possible to do efficient epoll emulation on windows so then I wrote wepoll. With it you can just stick to the good ol' epoll/kqueue model and still support windows.
    • rumcajz 9y ago
      How does it work? It's not obvious how epoll could be built on top of IOCP.
      • piscisaureus 9y ago
        It uses an ioctl that boils down to 'an overlapped version of poll()'. So the call doesn't block - instead when an event like POLLIN or POLLOUT happens, a completion is posted to the completion port. Call this overlapped-poll function on every monitored socket individually so you don't inherit poll()s scalability problems. See https://github.com/piscisaureus/wepoll/blob/437fb2f24ce197b47f5fb1100aa397e73e1872e1/src/afd.c#L20-L88 https://github.com/piscisaureus/wepoll/blob/437fb2f24ce197b4... This is as much of an explanation I can type on my phone - I'll add more detail to the wepoll readme later.
  • scadge 9y ago
    Sure, I understand. Was just curious about how they both relate, and now I get it.
• signa11 9y ago
  > So it looks like libuv could use libdill, right? libuv, has the follow (iirc) genealogy : libevent -> libev -> libuv like its predecessors (with the exception of libev i think) it has grown to be quite large, but its core is still centered on the concept of an event loop. the event-loop itself is hidden, and 'user' code interacts with it via callback event handlers. given this context, i still don't quite understand how/where libdill might play a role here ? fwiw, almost all of these event-processing libraries, supports multiple event loops, and thus an event loop is a first class citizen within the library, and implement functions for creating/destroying/starting/stopping loops. multiple event loops find their uses specifically in the context of multi-threaded servers for example.