Je suis en train de construire un site et une opération particulière déclenche l'exécution d'un long processus côté serveur. Cette opération ne peut pas être exécutée deux fois en même temps, et je dois donc mettre en place une sorte de protection. Elle ne peut pas non plus être rendue synchrone, car le serveur doit continuer à répondre à d'autres demandes pendant son exécution.
À cette fin, j'ai construit ce petit test conceptuel, en utilisant les éléments suivants sleep 5
comme substitut à mon processus actuel de longue durée (qui requiert express y processus-promesse d'enfant fonctionne sur un système avec un sleep
mais remplacez-la par n'importe quelle commande pour Windows) :
var site = require("express")();
var exec = require("child-process-promise").exec;
var busy = false;
site.get("/test", function (req, res) {
if (busy) {
res.json({status:"busy"});
} else {
busy = true; // <-- set busy before we start
exec("sleep 5").then(function () {
res.json({status:"ok"});
}).catch(function (err) {
res.json({status:err.message});
}).then(function () {
busy = false; // <-- finally: clear busy
});
}
});
site.listen(8082);
L'intention est que lorsque "/test" est demandé, il déclenche une longue opération, et si "/test" est demandé à nouveau pendant qu'il est en cours d'exécution, il répond par "occupé" et ne fait rien.
Ma question est la suivante : cette mise en œuvre est-elle sûre et correcte ? Elle semble fonctionner dans mes tests superficiels, mais elle est d'une simplicité suspecte. Est-ce la bonne façon d'implémenter un mutex + une opération "try-lock", ou existe-t-il une construction Node.js plus appropriée ? Venant de langages où je suis habitué à des pratiques de multithreading standard, je ne suis pas tout à fait Je ne suis pas encore à l'aise avec la nature monofilaire mais asynchrone de Node.