Comprendere l'alternativa JS al nodo multithreading

Se capisco correttamente il nodo JS non sta bloccando ... quindi invece di attendere una risposta da un database o da un altro processo è passato a qualcos'altro e ricontrolla più tardi.

Inoltre è a thread singolo.

Quindi tutto ciò significa che un determinato processo Node JS può utilizzare in modo completo ed efficiente un singolo core della CPU ma non utilizzerà nessun altro core sulla macchina, in quanto non ne utilizzerà mai più uno alla volta.

Questo ovviamente significa che le altre CPU possono ancora essere utilizzate da altri processi per cose come database SQL o altre subroutine di CPU volutamente separate fintanto che si tratta di un processo separato.

Anche nel caso in cui il processo Node JS abbia un ciclo infinito o una funzione di lunga durata, quel processo non è più utile in alcun modo fino a quando il ciclo infinito o la funzione di lunga durata viene interrotto (o l'intero processo viene interrotto).

Va tutto bene? Sono corretto nella mia comprensione?

Abbastanza corretto, sì. Il server node.js ha un pool di thread interno in modo da poter eseguire operazioni di blocco e avvisare il thread principale con un callback o un evento al termine delle operazioni.

Quindi immagino che farà un uso limitato di un altro core per il pool di thread, ad esempio se si fa un file system non bloccante leggere questo è probabilmente implementato dicendo a un thread dal pool di thread di eseguire una lettura e impostare un callback quando è fatto, il che significa che la lettura potrebbe avvenire su un thread / core diverso mentre il programma node.js principale sta facendo qualcos'altro.

Ma dal punto di vista node.js, è interamente a thread singolo e non utilizzerà direttamente più di un core.

Sì, direi che la tua comprensione è del tutto corretta. Questo articolo ( archiviato ) spiega abbastanza bene la logica alla base di questo disegno. Questo è probabilmente il paragrafo più importante:

Apache è multithread: genera un thread per richiesta (o processo, dipende dalla conf). Puoi vedere come quell'overhead consuma memoria all'aumentare del numero di connessioni simultanee e sono necessari più thread per servire più client simultanei. Nginx e Node.js non sono multithread, poiché thread e processi comportano un costo di memoria elevato. Sono a thread singolo, ma basati su eventi. Ciò elimina il sovraccarico creato da migliaia di thread / processi gestendo molte connessioni in un singolo thread.

Anche se questo è un vecchio thread, ho pensato, che condividerei con un'idea, come utilizzare più di un core nell'app Node.JS. Come ha detto Nuray Altin, JXcore può farlo.

Esempio semplice:

var method = function () {
    console.log("this is message from thread no", process.threadId);
};

jxcore.tasks.runOnThread(0, method);
jxcore.tasks.runOnThread(1, method);

// this is message from thread no 1
// this is message from thread no 0

Di default ci sono due thread (puoi cambiarlo con jxcore.tasks.setThreadCount())

Naturalmente c'è molto di più che puoi fare con le attività. I documenti sono qui .

Pochi articoli sull'argomento:

• In che modo le applicazioni JXcore multithread beneficiano di più core .
• Come trasformare la tua applicazione esistente in una multithread con poche righe di codice!

Da quando questa domanda è stata posta quasi 2 anni fa. Le cose stanno cambiando o ci sono approcci alternativi al problema del multithreading su Node.JS

Secondo il post di blog di seguito, utilizzando l'estensione 'task' in entrata, alcuni possono beneficiare direttamente di altri core disponibili.

http://oguzbastemur.blogspot.com/2013/12/multithread-nodejs.html

Node.js è un'applicazione a thread singolo, ma può supportare la concorrenza tramite il concetto di evento e callback. Ecco il video di Philip Roberts che spiega come funzionano i loop di eventi in javascript.

clicca qui per vedere il video

(Invece delle API Web ci sono API C ++ in Node.js)