相关疑难解决方法(0)

我正在构建一个站点,一个特定的操作会触发一个长的服务器端进程来运行.此操作不能同时运行两次,因此我需要实现某种保护.它也不能同步,因为服务器在运行时需要继续响应其他请求.

为此,我构建了这个小概念测试,sleep 5用来替代我实际的长期运行过程(需要快速和子进程承诺,在带有sleep命令的系统上运行,但替代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);

这样做的目的是当请求"/ test"时它触发一个长操作,如果在它运行时再次请求"/ test",它会回复"忙"并且什么都不做.

我的问题是,这种实施安全和正确吗？它似乎在我的粗略测试中起作用,但它很可疑.这是基本上实现互斥+ +"try-lock"操作的正确方法,还是有一些更合适的Node.js构造？从习惯于标准多线程实践的语言开始,我对Node的单线程但异步性质不太满意.

ES2018之前,我曾经窝额外then的承诺链的末端,每当我不得不执行任何清理逻辑,我想重复,否则在then和catch更高,如

new Promise(
  (res, rej) => setTimeout(() => rej({}), 1000)
).then(
  res => console.log(res)
).catch(
  err => console.error(err)
).then(
  () => console.log('Finally')
)

但是现在finally已经在Promise原型上添加了,我看不出它then与上述方法中的最后一个有什么不同.以下将产生相同的输出.

new Promise(
  (res, rej) => setTimeout(() => rej({}), 1000)
).then(
  res => console.log(res)
).catch(
  err => console.error(err)
).finally(
  () => console.log('Finally')
)

难道finally仅仅是服务于本地无极API在语义的目的是什么？