[ritchiea]

It's a C library to handle asynchronous IO. The library it replaced, libev, is essentially a wrapper around select which is a unix system call that looks for file descriptors that are ready for reading or writing (for more info you can use the command 'man select' in bash). My understanding is that select can be nondeterministic so there were predictability and performance improvements to be had by replacing it with a better model. The guide also links to this talk by one of the libuv authors which is a great help in understanding why they wrote libuv: https://www.youtube.com/watch?v=nGn60vDSxQ4

[jamwt]

This is not quite correct. libev is a wrapper around the best available of select/epoll/kqueue (the same syscalls libuv uses), and it provides nice timers, thread wake (eventfd/pipe), etc.

What it doesn't provide that libuv does is high-level support for asynchronous filesystem I/O, a built-in asynchronous DNS resolver, process management abstractions and more high-level cross platform goodies for writing asynchronous apps. libev also doesn't have very good support on windows.

So, the main improvements provided by libuv are a more extensive high-level API and good windows support. I doubt speed (or deterministic latency or scalability.. etc) was a goal, as libev is very, very fast. Just lower-level.

[onestone]

For the record, Node's I/O performance is better now that it's based on libuv (after libuv removed its own libev dependency) than when it was based on libev. This doesn't necessarily mean that libuv is always faster than libev, but at least for Node's use case it was.

[ritchiea]

Thanks for the clarification. My experience with system level IO calls is limited. I formed my answer from my experience and the Bert Belder talk I linked to above. He actually describes libev as a wrapper around select, and says that select is slow but he does clarify in his slides that libev also uses epoll/kqueue, which I didn't notice until returning to the talk after your comment.