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

21–28 of 28 posts

Re: An introduction to libuv

#21

Post by onestone »

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…

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.

Re: An introduction to libuv

#22

Post by baruch »

baruch wrote: post #20
qznc wrote: post #10

Earlier quoted context omitted.

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

As an undergrad I was thought about ADT (Abstract Data Type) and then the "proper" way was to provide a _new method to allocate the data. This also allowed to completely hide the type as the C header didn't need to show the content of the struct being allocated.

If you go with not malloc'ing internally then you need to expose the entire struct and I tend to go about it by using an extra header X_internal.h that is explicitly showing the internals but expects you not to abuse this knowledge.

It's a tradeoff and I currently tend towards the second option more often than not.

Re: An introduction to libuv

#24

Post by malkia »

Isn't this example wrong: (I'm not much familiar with libuv, but reading from the comments it might be):

http://nikhilm.github.io/uvbook/filesystem.html

  void on_read(uv_fs_t *req) {
       uv_fs_req_cleanup(req); // result result == 0) {
           uv_fs_t close_req;
           // synchronous
           uv_fs_close(uv_default_loop(), &close_req, open_req.result, NULL);
       }
       else {
           uv_fs_write(uv_default_loop(), &write_req, 1, buffer, req->result, -1, on_write);
       }
   }

Re: An introduction to libuv

#25

Post by 9oliYQjP »

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…

Just wondering if you could recommend some books or open source code that you'd consider to be a good role model of the kind of code you write. I use libuv in one of my projects and I was using it to better my C skills. I don't get to do C very much in my day job. But I'd like to be exposed to different styles of C so that I might understand why one style is used over another in a given context. Thanks.

Re: An introduction to libuv

#26

Post by jheriko »

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…

thanks. great reply. :)

tbh, i was angling for 'my criticism isn't great because i am a specialist in a specialist field'.

(also, it does look like a genuinely useful library for most use cases - im just lazy and want everyone else to do my job for me :P)

Re: An introduction to libuv

#27

Post by jheriko »

9oliYQjP wrote: post #25
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…

Just wondering if you could recommend some books or open source code that you'd consider to be a good role model of the kind of code you write. I use libuv in one of my projects and I was using it to better my C skills. I don't get to do C very much in my day job. But I'd like to be exposed to different styles of C so that I might understand why one style is used over another in a given context. Thanks.

this is part of the problem. most of it is locked away in proprietary source codes - something i am hoping to fix in the coming months by putting something into the public domain myself. :)

Re: An introduction to libuv

#28

Post by nsm »

malkia wrote: post #24

Isn't this example wrong: (I'm not much familiar with libuv, but reading from the comments it might be): http://nikhilm.github.io/uvbook/filesystem.html void on_read(uv_fs_t *req) { uv_fs_req_cleanup(req); // result result == 0) { uv_fs_t close_req; // synchronous uv_fs_close(uv_default_loop(), &close_req, open_req.result, NULL); } else { uv_fs_write(uv_default_loop(), &write_req, 1, buffer, req->result, -1, on_write…

It's correct. uv_fs_req_cleanup() deletes some private data associated with the uv_fs_t. `result` is part of the public interface and is unaffected.
Post reply on HN