5 ms·
Is there a detailed overview about which functions in libuv (Nodejs) rely on blocking primitives and thus are using the thread pool to work async? From [here](
by albertzeyer 12y ago
Is there a detailed overview about which functions in libuv (Nodejs) rely on blocking primitives and thus are using the thread pool to work async?
From [here](http://docs.libuv.org/en/latest/design.html http://docs.libuv.org/en/latest/design.html), it sounds like all file IO is always based on blocking primitives, and native async file IO primitives are not used, although such async file IO primitives do exists and were tried out in libtorrent (http://blog.libtorrent.org/2012/10/asynchronous-disk-io/ http://blog.libtorrent.org/2012/10/asynchronous-disk-io/). The result of that experiment however was mostly that the thread pool solution was simpler to code (I guess).
From the libuv design doc, the overview is:
* Filesystem operations
* DNS functions (getaddrinfo and getnameinfo)
* User specified code via uv_queue_work()
I wonder whether this is really the best solution of if some combination of a thread pool and native async disk IO primitives could perform better.
- deleted 12y ago[deleted]
- albertzeyer 12y agoYes, just read that (the libtorrent post). I somehow feel that this is a sad state. Shouldn't we try to improve the disk AIO API then, if it is not useful at the moment? Or maybe that has changed also? The article is from 2012. Or maybe we could at least partly use it? Of course, code complexity will be a problem then in any case. But for applications depending on a lot of concurrent disk IO, maybe it could be worth it.
- masklinn 12y ago> The result of that experiment however was mostly that the thread pool solution was simpler to code (I guess). and uniformly asynchronous (native async operations may not cover e.g. file copy or filesystem operations, furthermore filesystems may block during submission of IO ops which makes the operations effectively synchronous) and have higher throughput (they support read/write vectors).
- albertzeyer 12y agoWe could use the thread pool for blocking primitives and otherwise use the native AIO primitives, couldn't we? And the higher throughput seemed only to be a problem on MacOSX, so we could fallback to the thread pool there, but use the async IO on Windows and Linux.
- laggyluke 12y agoI thought that's basically what libuv does: it uses AIO on platforms that support it, falling back to thread pool on platforms that don't. Edit: apparently I was wrong.
- inquisitiveio 12y agoThe article you link to touches on a few of the Linux AIO shortcomings. But if you have also read the following blunt criticism from Linus http://yarchive.net/comp/linux/o_direct.html http://yarchive.net/comp/linux/o_direct.html he also outlines a better alternative way of implementing asynchronous disk io on Linux at least.