Javascript的回调，不等同于MCU的中断

曾有一位做单片机开发的朋友问我回调是怎么回事，我解释就跟单片机的中断函数类似，比如你的定时器的溢出值设置为200毫秒，那么单片机内部电路每200毫秒，就会把PC设置成你的定时器中断向量入口，达到调用中断程序的目的。在浏览器上，JS引擎负责做这个事，回调函数就相当于ISR。

后来一想，这种说法有问题。只怪我当时对Javascript的特性不是很了解。表面上看它很恰当，但是却让人忽略了一些重要的问题。MCU的中断，是那种会直接打断程序流程的东西，而Javascript的回调，会很绅士地一直等下去。

还是拿「定时器中断」来说，当定时器的计数器溢出或达到阈值，就会改变内部一个标志位。正在运行的指令执行完后，这个中断标志就会被处理，不同的MCU会有不同的处理方式。

大致原则是：

也就是说，基本上MCU会立即响应！

单片机工程师在这一块会非常小心，举个例子，当MCU字长小于数据的字长，比如在8位机上使用int，如果这个值碰巧也会被ISR修改，就需要在处理int前，先关掉全局中断，处理完了重新打开。因为你不知道什么时候中断会产生并打断你。

出于类似的原因，软件开发人员编写多线程程序时，经常需要「加锁」。

我们拿JS的setTimeOut来做个实验。（正好和定时器中断做个对比）

setTimeout(() => console.log("cool"), 1000)

这个会在1秒钟后，打印出一个“cool”。一切在预期中，与「MCU中断」行为类似。

举其他的例子之前，我们先定义一个函数，通过死循环来达到延时的效果。

function sleepSync(ms) {
  var mark = new Date().getTime()
  while (new Date().getTime() - mark < 4000)
}

再看另外一个例子

setTimeout(() => console.log("cool"), 1000)
sleepSync(4000)

出问题了，过了4秒之后才打印出“cool”。setTimeout并不能打断那个while死循环。

用其他的Javascript函数做个实验

// let's try to read a non-existing file
fs.readFile("/tmp/blah", (e, _) => console.log(e.message))
sleepSync(4000)

同样是过了4秒，才打印出

ENOENT: no such file or directory, open '/tmp/blah'

所以JS的「回调」和「MCU的中断」，是不能等同的，它们有一些相似点，但是在关键的地方不太一样，所以以后还是不要打这个比方吧。

至于Javascript为什么是这个样子，这跟Javascript的Event Loop和task queue有关了，但那是另外一个主题（如果感兴趣，请看另一篇博客），这篇文章只是纠正一下过去自以为很棒的比喻。

原文：http://madmuggle.me/articles/JSCallbackIsNotMCUInterrupt.html