Confusion about node.js internal asynchronous I/O mechanism

Question

1. I have learned that node.js use libeio internally to perform async file I/O, with thread pool, on *nix platform, am I right?
2. What about async network I/O? Is it done by libev? Is there also a thread pool?
3. If there is thread pool inside, how could it be more efficient than traditional one-thread-per-request model? And is it one thread per I/O request?
4. And what's the mechanism on windows? I know it's done by IOCP, and there's a kernel level thread pool, right?
5. Why linux doesn't have a native completely AIO mechanism like windows IOCP yet? Will it have in future?

Update according to changchang's answer:

1. I took a quick view at the source code @changchang have given, found that the default thread pool size can be reset by UV_THREADPOOL_SIZE, I'm wondering in which case this will be used?
2. I also found getaddrinfo use this thread pool, is there any more except fs? And if all sync jobs will be done in this thread pool, is the default size '4' enough?
3. As my understanding now, there will be 6 basic threads in node.js process: 1 V8 thread(event loop, where user javascript codes runs), 1 libuv event loop, and 4 in thread pool, am I right?

4. And how can I see these threads in my shell(Ubuntu)? I use ps -eLf | grep node | grep -v grep only saw two:

   root 16148 7492 16148 0 2 20:43 pts/26 00:00:00 ./bin/node /home/aaron/workspace/test.js
   root 16148 7492 16149 0 2 20:43 pts/26 00:00:00 ./bin/node /home/aaron/workspace/test.js

Answer 1

1. First of all, libuv has removed the libeio from it. But it does perform async file I/O with a thread pool like libeio just as you mentioned.

2. libuv also removes libev. It does the async network I/O based on the async I/O interfaces in different platforms, such as epoll, kqueue and IOCP, without a thread pool. There is a event loop which runs on the main thread of uv which polls the I/O events and processes them.

3. The thread pool inside libuv is a fixed size thread pool (4 in uinx like system). It performs a task queue role and avoids the exhaustion of the system resources by generating threads indefinitely when the requests increase.