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), 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/). 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.
The 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 he also outlines a better alternative way of implementing asynchronous disk io on Linux at least.
> 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).
We 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.
Yes, 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.
From [here](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/). 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.