2016-01-06 12 views
6

Ho un processo Node.js (non un server) che forca processi figlio N. Ad un certo punto potrebbero esserci più di 50 CP. Quindi ho iniziato a pensare che se process.send (IPC) stia veramente bloccando, allora questa potrebbe essere una grande penalità vissuta da ciascun CP. Perché ciò che accade nel mio programma è che ogni CP usa process.send per inviare un messaggio al processo genitore singolo in modo che il genitore esegua la registrazione, in modo che la registrazione sia sincronizzata. Ma se process.send blocca allora a un certo punto il processo genitore potrebbe diventare un collo di bottiglia.process.send è sync/async su * nix/Windows?

Quindi la domanda è: Node.js IPC è bloccato o non bloccante su * nix e Windows? Se si sta bloccando e se io o qualcun altro volessimo davvero IPC asincrono, dovrei usare una coda di messaggi o ZeroMQ o qualcosa del genere?

risposta

8

processo di invio è stato impostato asincrono, vedere https://github.com/nodejs/node/commit/56d9584a0ead78874ca9d4de2e55b41c4056e502

"`ChildProcess.prototype.send()` and `process.send()` used to operate 
synchronously but became asynchronous in commit libuv/[email protected]" 

ciò è dovuto a cambiamenti nel codice libuv; presenta alcuni inconvenienti, ma se sei preoccupato che il processo genitore diventi il ​​collo di bottiglia potresti usare le pipe per la comunicazione.

50 CP non saranno un problema, ma 500 potrebbe, a seconda dell'architettura e della dimensione dei messaggi. A quel punto raccomanderei una coda di messaggi che è un po 'più elegante. ZeroMQ o normali redis dovrebbero funzionare.

+1

in realtà, se si legge il collegamento Github, si dice che process.send è stato impostato su asincrono, non sincrono, che è una buona notizia –

+3

"' ChildProcess.prototype.send() 'e' process.send() ' utilizzato per operare in modo sincrono ma diventa asincrono in commit libuv/libuv @ 393c1c5 " –

Problemi correlati