Perché Node non supporta più loop di eventi in un processo?

3

Come dice il titolo, perché il nodo non supporta diversi loop di eventi in un processo? L'idea è che il nodo genera un numero di thread decisi dall'utente, ognuno dei quali ha un ciclo di eventi. Quando viene aggiunto un nuovo callback, è programmato su uno dei loop dei thread. Il motivo, probabilmente contro questa idea è perché ora ogni thread può causare la mutazione e altre cose brutte, ma puoi decidere all'utente quale thread condividere lo stato e quindi deve essere eseguito sullo stesso thread o avere un messaggio come il concetto di condivisione della memoria degli eventi . Ciò aiuterebbe con compiti computazionalmente pesanti, questo ridurrebbe il sovraccarico di condivisione dei dati tra le istanze dei nodi per ottenere lo stesso risultato e quindi ottenere migliori prestazioni per l'hardware e più richieste dell'utente.

Per renderlo più chiaro, quando intendo diversi loop di eventi, sarebbe come biforcarsi e creare diverse istanze di nodo per utilizzare più core, ma invece il nodo stesso genererà 4 thread tutti con un ciclo di eventi, quindi c'è un valore inferiore costo della comunicazione perché utilizza thread invece se le istanze se si sta facendo un sacco di condivisione dei dati, non i lavoratori che si generano per fare lavori pesanti e non hanno nulla a che fare con il ciclo degli eventi.

    
posta Coder3000 28.12.2015 - 09:24
fonte

1 risposta

5

Non appena hai diversi thread in esecuzione nello stesso processo e condividendo lo stesso spazio di indirizzi virtuali , hai problemi sincronizzazione e probabilmente avrai bisogno di mutexes (ad es. per trattare il caso di diversi loop di thread che accedono contemporaneamente allo stesso oggetto ).

(presumo un sistema operativo Linux con pthreads di seguito)

Quindi avrai bisogno di estendere la lingua Javascript per quello; o aggiungerai in modo trasparente i mutex in ogni oggetto rendendoli più pesanti (un pthread_mutext_t ha 40 byte sul mio Linux / Debian / x86-64) e più lento (dovrai chiamare qualcosa come pthread_mutex_lock ad ogni accesso), o metti quell'onere sull'utente, costringendolo a aggiungere un codice aggiuntivo e ad aggiungere un nuovo modo di indefinito comportamento e possibilità di deadlock .

Infine, la garbage collection multi-threading è piuttosto difficile. Leggi il manuale GC per ulteriori informazioni.

BTW, su molti sistemi Linux, i processi sono quasi altrettanto efficienti e facili da avviare come thread (si veda clone (2) usato da pthreads e talvolta come sostituto alla fork (2 ...), quindi avere decine di processi Node.js ha senso. Inoltre, IPC locale (ad es. Attraverso pipe (7) -s o unix (7) -s socket) è molto efficiente su Linux, quindi i costi di comunicazione possono essere piuttosto bassi (di solito più di dieci volte più veloce di Ethernet su una rete locale).

    
risposta data 28.12.2015 - 09:35
fonte

Leggi altre domande sui tag