undefined | Better HN

0 pointsjamwt12y ago0 comments

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.

0 comments

onestone12y ago

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.

ritchiea12y ago

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.

j / k navigate · click thread line to collapse

0 pointsjamwt12y ago0 comments

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.

0 comments

onestone12y ago

ritchiea12y ago

j / k navigate · click thread line to collapse