Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An introduction to libuv

nikhilm.github.io

Post reply on HN
Print view View original

11–20 of 28 posts

Re: An introduction to libuv

#11

Post by SpikeGronim »

josephg wrote: post #2

I've written a couple of C tools directly on top of libuv[1] to play with it. I've got to say, its a great little library. Its basically nodejs's entire cross-platform standard library & event loop exposed to C, without V8 and without npm. It performs well, the code is pretty high quality and the internal documentation is excellent. The external API docs aren't very good though - I found myself reading through nodejs…

Redis doesn't use libuv, and in fact rejected a patch from MS to add libuv support. The reason is dependency management, not performance. Redis takes very very few dependencies - basically just a C compiler and POSIX. This makes it easier to deploy Redis, and Redis doesn't have to worry about failures in its non-existent dependencies.

Re: An introduction to libuv

#12

Post by qznc »

jheriko wrote: post #7

i am always a bit of jerk about these things because i constantly work with genuinely performance critical code, but the very first thing puts me off: uv_loop_t* loop = uv_loop_new(); does the compiler know where this exists, is it allocated on demand, is there a lock involved? i hope to get the good answers to these questions but the naming of the function alone makes me skeptical. this skepticism turns out to be ju…

My theory: The library was designed for Node.js, not for ultimate performance. Design for Node.js means "easy to create bindings for", which means opaque pointers instead of structs in the API.

Re: An introduction to libuv

#13

Post by JoachimSchipper »

jheriko wrote: post #7

i am always a bit of jerk about these things because i constantly work with genuinely performance critical code, but the very first thing puts me off: uv_loop_t* loop = uv_loop_new(); does the compiler know where this exists, is it allocated on demand, is there a lock involved? i hope to get the good answers to these questions but the naming of the function alone makes me skeptical. this skepticism turns out to be ju…

Genuine question: why would you want to create a significant numbers of loop contexts? (Your way does sometimes save one pointer dereference, but that's not what you appear to be talking about.)

Re: An introduction to libuv

#14

Post by shavenwarthog2 »

kyberias wrote: post #3

Is there some introductory text available explaining what is the purpose of libuv, it's intended usage scenarios etc.?

high performance I/O library, with Windows support. I'm happy to note it has bindings for a lot of languages, including Python:

https://github.com/joyent/libuv/wiki/Projects-that-use-libuv

I'm very familiar with Twisted, Perl AnyEvent, and Gevent/Greenlet -- libuv seems to be like that.

Re: An introduction to libuv

#16

Post by KenoFischer »

bnoordhuis wrote: post #9
jheriko wrote: post #7

i am always a bit of jerk about these things because i constantly work with genuinely performance critical code, but the very first thing puts me off: uv_loop_t* loop = uv_loop_new(); does the compiler know where this exists, is it allocated on demand, is there a lock involved? i hope to get the good answers to these questions but the naming of the function alone makes me skeptical. this skepticism turns out to be ju…

Libuv author here. Libuv doesn't try to be all things to all people - its main users are Node.js and Rust - but if you have suggestions on how to improve the API or the implementation, please file issues[1] or join us in #libuv on irc.freenode.org. We welcome outside input. As a bit of history, the reason why uv_loop_new() mallocs memory for the struct (and it's something of an anomaly in that respect, most other API…

And Julia! :)

Re: An introduction to libuv

#17

Post by _wmd »

jheriko wrote: post #7

i am always a bit of jerk about these things because i constantly work with genuinely performance critical code, but the very first thing puts me off: uv_loop_t* loop = uv_loop_new(); does the compiler know where this exists, is it allocated on demand, is there a lock involved? i hope to get the good answers to these questions but the naming of the function alone makes me skeptical. this skepticism turns out to be ju…

Various parts of libuv (e.g. the recv path) have pluggable allocators. I'm more interested in why you'd be wanting to create and destroy event loops at a high rate? That seems to imply you're perhaps creating and destroying threads at a high rate, in which case, you have bigger problems than malloc.

Re: An introduction to libuv

#18

Post by jamwt »

ritchiea wrote: post #5
kyberias wrote: post #3

Is there some introductory text available explaining what is the purpose of libuv, it's intended usage scenarios etc.?

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…

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.

Re: An introduction to libuv

#19

Post by ritchiea »

jamwt wrote: post #18
ritchiea wrote: post #5

Earlier quoted context omitted.

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…

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 asynchronou…

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.

Re: An introduction to libuv

#20

Post by baruch »

qznc wrote: post #10
ricardobeat wrote: post #8

Earlier quoted context omitted.

In general, you can always do a better job than any given library for your specific use case. That might mean 10x more work though, it's all about choices/compromises.

He probably wants an alternative like: uv_loop_t loop; uv_loop_init(&loop);

That would be my preference. And contrary to what others thought that one would want a lot of these loops, when you want only a few, especially when those few are fixed for the entire program life you can do better by avoiding malloc altogether.

Could be my preference for working on systems that never malloc and only use specific pools and rely on knowing their exact memory requirements from the start to the end. I can acknowledge that this may be more anal than normal but then if the library didn't allocate in my name I could choose to allocate on heap or use it in a static fashion as I please.

Post reply on HN