Come scoprire se ci sono ancora eventi registrati nel ciclo degli eventi (bonus: quanti)

Question

Sto provando a scrivere un programma Node.js per eseguire e monitorare i programmi javascript. Sto cercando un modo per scoprire se il programma monitorato è ancora "in esecuzione", cioè fare qualcosa di utile.

Nel mio approccio attuale, quando ricevo il codice da testare, avvio un nuovo processo figlio e mi porto il codice. Gli strumenti del processo figlio il codice crea una sandbox utilizzando Contextify ed esegue il codice utilizzando questa sandbox.

Dopo la chiamata sandbox.run(code), so che la parte di blocco del codice è stata completata e può essere mostrata nell'interfaccia utente. Tuttavia, ora non so se il codice abbia registrato qualsiasi timer usando setTimeouts o creato qualsiasi altra fonte di eventi che possa causare l'uscita successiva di parti del codice. Quindi non so se è davvero "finito" ancora.

C'è un modo in Node.js per verificare se ci sono ancora eventi sul ciclo degli eventi da gestire (o anche meglio, quanti ne rimangono)?

Ho trovato this other question, ma si parla solo di come monitorare il ciclo degli eventi per scoprire se le prestazioni del nodo sono ancora valide. Ma non mi interessa la performance (non mi interessa se il codice in esecuzione sta bloccando per 10 secondi o sta facendo qualcosa per 1ms ogni 2 minuti) e non voglio usare strumenti esterni, ma scoprire lo stato di il ciclo degli eventi dal nodo interno stesso. È possibile?

Answer 1

Ho risolto il mio problema in un modo, anche se non ho trovato una risposta generale alla domanda.

L'idea è che il processo uscirà da solo se ha eseguito tutto il codice con cui è stato avviato e non sono più registrati EventEmitters. Questo era fondamentalmente quello che volevo, dal momento che volevo ricevere una notifica quando il processo era "finito" e ora potevo semplicemente ascoltare l'evento "exit" del processo figlio.

Ma il mio processo che ha eseguito il codice non è uscito da solo. Ciò aveva due ragioni:

1. Ho utilizzato un timer per inviare regolarmente i dati raccolti sull'esecuzione al processo padre. Se viene registrato un timer di questo tipo, il processo non verrà interrotto. Si potrebbe unref il timer ma temevo che avrebbe portato alla perdita di dati in quanto il processo potrebbe uscire prima che l'ultimo bit di dati è stato inviato (dal momento che non aspetterebbe l'esecuzione del timer). Così ho cambiato il mio codice per programmare un timer solo se c'erano dei dati da inviare invece di controllare regolarmente i dati da inviare.
2. Ho utilizzato fork per creare il processo figlio. Questo crea anche un canale di comunicazione tra il processo genitore e figlio e poiché ho bisogno di inviare il codice da eseguire al processo figlio ho registrato il processo figlio per i messaggi ricevuti dal genitore usando process.on("message", callback). Tuttavia, ora abbiamo un altro EventEmitter registrato che impedisce al processo di uscire. Fortunatamente, mi sono reso conto che avevo solo bisogno di un messaggio dal processo genitore e nessun altro messaggio in modo da poter rimuovere l'emettitore di eventi dopo aver ricevuto quel messaggio. Quindi, invece di process.on() ho usato process.once() che eseguirà il callback solo una volta e rimuoverà automaticamente l'emettitore di eventi successivamente. Esattamente quello che volevo. In alternativa è possibile utilizzare process.removeListener().

Ora non vedo l'ora che esca il processo figlio e sappia che tutto è terminato e può avvisare il cliente.

Quindi la soluzione qui è assicurarsi che nessuno dei vostri EventEmitter mantenga vivo il processo e quindi aspetti che esca.