https://nodejs.org/api/process.html`exit` Ereignis in node.js verhält sich anders als im Handbuch
Listener-Funktionen nur synchrone Operationen durchführen müssen. Der Prozess Node.js wird unmittelbar nach dem Aufruf des Exit-Ereignisses listeners beendet, wodurch zusätzliche Arbeit in der Ereignisschleife abgebrochen wird. Im folgende Beispiel zum Beispiel auftreten, das Timeout nie:
process.on('exit', (code) => {
setTimeout(() => {
console.log('This will not run');
}, 0);
});
Jetzt habe ich dies in meinem main.js:
if (errors) {
process.exitCode = 1;
}
process.emit("exit");
In einem Logger, die Shutdown-Zuhörer etc I hat eine mongo Verbindung und die folgende:
process.on("exit", (code) => {
if (this.status.finishedAt === null) {
this.status.currentState = StatusUpdater.STATE_STOPPED;
this.status.finishedAt = new Date();
this.persistStatus()
.then(() => {
this.mongoDb.close().then(() => {
setTimeout(() => {
console.log('byebye');
process.exit(code);
}, 5000);
});
})
.catch(this.noMongoConnection);
}
});
Der Ausgang ist: byebye
nach 5 Sekunden.
Jetzt bin ich verwirrt. Offensichtlich kann ich asynchrone Operationen ausführen, nachdem das Ereignis exit
ausgelöst wurde. Das Handbuch sagt, das ist nicht möglich.
Was ist richtig und was ist falsch?
Der Aufruf von 'process.exit (code);' im 'exit' Event-Handler ist sehr seltsam. Ich frage mich, ob dies tatsächlich alle Ihre Handler zweimal auslösen wird. – Bergi
@Bergi tut es, also überprüfe ich, ob das 'finishedAt' nicht undefiniert ist. Auch wenn Sie ein 'SIGINT' auslösen, wird das' exit' Ereignis auch danach aufgerufen. – DanFromGermany
@Bergi Hast du eine Idee für einen Shutdown-Handler, außer wie ich es gemacht habe? Der einzige Nachteil meiner Lösung ist, dass, wenn es einen anderen Exit-Listener gibt und eine Chance besteht, nicht ausgeführt zu werden, wenn ich die 'process.exit()' vor diesem anderen Listener mache. – DanFromGermany