Confusione circa Node.JS meccanismo interno I/O asincrono

Question

1. Ho imparato che utilizzano node.js libeio internamente per eseguire async lima I/O, con pool di thread, sulla piattaforma * nix, ho ragione?
2. Che dire di rete asincrona I/O? È fatto da libev? C'è anche un pool di thread?
3. Se è presente un pool di thread, come potrebbe essere più efficiente del modello tradizionale a thread singolo per richiesta? Ed è un thread per richiesta I/O?
4. E qual è il meccanismo su Windows? So che è fatto da IOCP, e c'è un pool di thread a livello di kernel, giusto?
5. Perché Linux non ha ancora un meccanismo nativo completamente AIO come Windows IOCP? Avrà in futuro?

Aggiornamento in base alla risposta di Changchang:

1. ho preso una vista veloce al source code @changchang hanno dato, ha scoperto che la dimensione del pool di thread predefinito può essere resettato UV_THREADPOOL_SIZE, mi chiedo nel qual caso sarà usato?
2. Ho anche trovato getaddrinfo usare questo pool di thread, c'è altro oltre a fs? E se tutti i lavori di sincronizzazione verranno eseguiti in questo pool di thread, la dimensione predefinita '4' è sufficiente?
3. Come ho capito ora, ci saranno 6 thread di base nel processo node.js: 1 thread V8 (loop eventi, dove vengono eseguiti i codici javascript dell'utente), 1 ciclo di eventi di libuv e 4 in pool di thread, ho ragione?

4. E come posso vedere questi thread nella mia shell (Ubuntu)? Io uso ps -eLf | nodo grep | grep -v grep visto solo due:

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

Answer 1

1. Innanzitutto, libuv ha rimosso il libeio da esso . Ma esegue l'I/O di file asincrono con un pool di thread come libeio proprio come hai menzionato.

2. libuv rimuove anche libev. Effettua l'I/O di rete asincrono basato sulle interfacce I/O asincrone su diverse piattaforme, come ad esempio epoll, kqueue e IOCP, senza un pool di thread. Esiste un ciclo di eventi che viene eseguito sul thread principale di uv che esegue il polling degli eventi I/O e li elabora.

3. Il pool di thread all'interno di libuv è un pool di thread di dimensioni fisse (4 in uinx like system). Esegue un ruolo di coda delle attività ed evita l'esaurimento delle risorse di sistema generando thread indefinitamente quando le richieste aumentano.

Answer 2

Uptil versione 0.6 nodo utilizzato per eseguire libev evento-loop e libeio per I/O asincrono, (backend Unix siede pesantemente su queste due librerie).Ma libuv ha iniziato a sostituire libev e libeio in version 0.8. Esegue, mantiene e gestisce tutti gli io e gli eventi nel pool di eventi. libuv è la scelta tra librerie IO asincrone multipiattaforma.

1. Sì, nodo fino a 0,6, deprecated in 0.8 e utilizza pool di thread

2. Sì, ma libev non utilizza pool di thread. Vedere here

   Chiarimento: Secondo il link nel question ho postato, libeio supporta tutte le funzioni POSIX si occupano di I/O (che comprende presa). Ma l'autore del nodo ha deciso di utilizzarlo solo per l'I/O di file asincrono e utilizza libev per l'I/O di rete. Non so da dove lo hai sentito, ma puoi usare epoll su file normali.

3. libev utilizza il ciclo degli eventi quindi nessun problema qui.

4. Sì IOCP gestisce l'I/O asincrono in Windows, il kernel utilizza i pool di thread.
5. Il nuovo kernel linux ha epoll, kqueue nel nuovo kernel BSD. libev e libeio erano per ambiente Linux e fornisce loop di eventi/IO asincrono per tutto il kernel (supporta select, poll, epoll, kqueue).

domande Aggiornamento:

1. non so molto su di libuv
2. forse sufficiente (non so)

3. Qui ci sono i miei risultati su Windows 8, controllato tramite Process Explorer. Sono stati mostrati 4 thread, 1 DLL, 1 file e 1 sezione (totale 7 voci) per un processo di applicazione del nodo.

4. ps -eLf mostra tutti i thread e processi, forse si sta filtrando troppo, basta cercare il pid di processo del nodo come ps -eLf | grep x dove x è il pid per il processo del nodo.