An introduction to libuv
nikhilm.github.io
An introduction to libuv
1–10 of 28 posts
Re: An introduction to libuv
#2I'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 a few times to figure out how I was expected to use some of the functions.
I'm quite curious to see how much performance you lose through libuv compared to using the lower level IO primitives directly (epoll, select and friends). I know redis doesn't use any high level event libraries, but I haven't seen any benchmarks.
[1] https://github.com/josephg/sharedb (Caveat: This was an experiment and libuv has probably changed in incompatible ways since I wrote this code)
Re: An introduction to libuv
#3Is there some introductory text available explaining what is the purpose of libuv, it's intended usage scenarios etc.?
Re: An introduction to libuv
#4Is there some introductory text available explaining what is the purpose of libuv, it's intended usage scenarios etc.?
libuv is like libev and libevent, but with an async API instead of a level-triggered readiness notification API. It was specifically written for Node.js because libev didn't work for them anymore at some point (e.g. limited usefulness on Windows).
Re: An introduction to libuv
#5Is 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 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
Re: An introduction to libuv
#6http://redis.io/topics/internals-rediseventlib ae is good too.
Re: An introduction to libuv
#7i 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 justified.
digging in:
loop = (uv_loop_t* )malloc(sizeof(uv_loop_t));
so the answers to all of my questions are the wrong ones for me. i might override the allocator to be less rubbish in my context. but simple things like this tell me that this library was not architected for the kinds of performance considerations that i need to make.
at this high level its not so important, but the more digging i do the 'worse' it gets...
generally this does look helpful, but it gives me nothing over my existing solutions (in my context) which, for example, require zero run-time memory allocations - outside of OS level API calls that I have zero control over - and lean heavily towards lockless implementations, avoiding the massively (but understandably) heavyweight OS provided threading primitives...
thread safety of malloc and other standard library (i.e. libc) type stuff is, in reality, up to the implementor. even when things have no requirement to be thread safe implementors (Microsoft) will often insert what i call 'sledgehammer thread safety' to protect bad programmers from themselves. i can understand why, but it prevents me from being able to use these libraries.
when i can do a better job than your standard library, you have failed imo. but it is just my opinion...
Re: An introduction to libuv
#8i 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…
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.
Re: An introduction to libuv
#9i 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 functions don't) is that the thing that came before libuv, libev, worked like that. It's something we can change if there is demand for it.
Re: An introduction to libuv
#10i 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…
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);