Thread pool come quando e chi ha usato:
Prima di tutto, quando usiamo / installiamo Node su un computer, avvia un processo tra gli altri processi che viene chiamato processo del nodo nel computer e continua a funzionare finché non lo uccidi. E questo processo in esecuzione è il nostro cosiddetto thread singolo.
Quindi il meccanismo del thread singolo rende facile bloccare un'applicazione del nodo ma questa è una delle caratteristiche uniche che Node.js porta in tavola. Quindi, ancora una volta, se esegui l'applicazione del nodo, verrà eseguita in un solo thread. Non importa se hai 1 o un milione di utenti che accedono alla tua applicazione contemporaneamente.
Quindi capiamo esattamente cosa succede nel singolo thread di nodejs quando avvii l'applicazione del nodo. All'inizio il programma viene inizializzato, quindi viene eseguito tutto il codice di primo livello, il che significa che tutti i codici che non sono all'interno di alcuna funzione di callback ( ricorda che tutti i codici all'interno di tutte le funzioni di callback verranno eseguiti in loop di eventi ).
Dopodiché, tutto il codice dei moduli eseguito quindi registra tutti i callback, infine, il ciclo di eventi è iniziato per la tua applicazione.
Quindi, come discusso in precedenza, tutte le funzioni di callback e i codici all'interno di tali funzioni verranno eseguiti in un ciclo di eventi. Nel loop degli eventi, i carichi sono distribuiti in diverse fasi. Ad ogni modo, non discuterò del loop di eventi qui.
Bene, per il sacco di una migliore comprensione del pool di thread, ti chiedo di immaginare che nel ciclo di eventi, i codici all'interno di una funzione di callback vengano eseguiti dopo aver completato l'esecuzione di codici all'interno di un'altra funzione di callback, ora se ci sono alcune attività sono effettivamente troppo pesanti. Quindi bloccherebbero il nostro thread singolo nodejs. E così, è qui che entra in gioco il pool di thread, che è proprio come il ciclo di eventi, fornito a Node.js dalla libreria libuv.
Quindi il pool di thread non fa parte di nodejs stesso, è fornito da libuv per scaricare compiti pesanti su libuv, e libuv eseguirà quei codici nei propri thread e dopo l'esecuzione libuv restituirà i risultati all'evento nel ciclo degli eventi.
Il pool di thread ci fornisce quattro thread aggiuntivi, questi sono completamente separati dal thread singolo principale. E possiamo effettivamente configurarlo fino a 128 thread.
Quindi tutti questi thread insieme hanno formato un pool di thread. e il ciclo di eventi può quindi scaricare automaticamente attività pesanti nel pool di thread.
La parte divertente è che tutto questo accade automaticamente dietro le quinte. Non siamo noi sviluppatori a decidere cosa va al pool di thread e cosa no.
Ci sono molte attività che vanno al pool di thread, come
-> All operations dealing with files
->Everyting is related to cryptography, like caching passwords.
->All compression stuff
->DNS lookups