Hacker News Reader

Comment by scadge | Hacker News Reader

I read that NodeJS is written in C with the same concept in its core - asynchronous on one core (thread) with interruptions. How does it compare to libdill?

View on HN

Node runs on top of libuv. https://nikhilm.github.io/uvbook/basics.html#hello-world

So it looks like libuv could use libdill, right?

Could have, possibly, but makes no sense at all to retrofit libuv with libdill at this point

Sure, I understand. Was just curious about how they both relate, and now I get it.

Shameless(-ish) plug: https://github.com/piscisaureus/wepoll is not a fat abstraction layer but it could help with windows support.

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.

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.

How does it work? It's not obvious how epoll could be built on top of IOCP.

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/437fb2f24ce197b4...

This is as much of an explanation I can type on my phone - I'll add more detail to the wepoll readme later.

> 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.

Reply on news.ycombinator.com