转载|网络编程中阻塞式函数的底层逻辑

逛知乎看到的，觉得写的挺透彻的，转载一下，原文链接：Unix网络编程里的阻塞是在操作系统的内核态创建一个线程来死循环吗？
原文以阻塞式的recv函数作为讲解，但是所有阻塞式的api底层逻辑基本相通。
下面是正文：

作者：张彦飞
链接：https://www.zhihu.com/question/492983429/answer/2236327954
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

大家天天都在说阻塞，实际上95%的程序员并没有真正理解阻塞是啥。这里并没有循环的事情，我们来从内核视角详细剖析一下阻塞到底是啥，它是如何工作的。把问题再具体一下，recv 接收数据阻塞的原理是啥？理解了这个就能真正理解所有的阻塞了。用一段大家都熟悉的代码来举例！

int main()
{int sk = socket(AF_INET, SOCK_STREAM, 0);connect(sk, ...)recv(sk, ...)
}

在上面的 demo 中虽然只是简单的两三行代码，但实际上用户进程和内核配合做了非常多的工作。大致的工作流程如下：
看到这里，你可能还没看着阻塞的原理。别着急，往下看。我们来看 recv 函数依赖的底层实现。首先通过 strace 命令跟踪，可以看到 clib 库函数 recv 会执行到 recvfrom 系统调用。进入系统调用后，用户进程就进入到了内核态，通过执行一系列的内核协议层函数，然后到 socket 对象的接收队列中查看是否有数据，没有的话就把自己添加到 socket 对应的等待队列里。最后让出CPU，操作系统会选择下一个就绪状态的进程来执行。
整个流程图如下：

以上这个流程图是我根据 Linux 内核源码的执行过程总结后画出来的。注意上面的第四步和第五步。第四步中是在访问 sock 对象下面的接收队列，如果接收队列中还没有数据到达，那么就会进入第五步，把当前进程阻塞掉。但是在把自己阻塞掉之前，进程干了一件事，给 socket 上留了个标记。告诉内核，如果这个 socket 上数据好了，记得叫我起来哈！就是源码 prepare_to_wait 函数中的 __add_wait_queue 这一句。

//file: kernel/wait.c
void
prepare_to_wait(wait_queue_head_t *q, wait_queue_t *wait, int state)
{unsigned long flags;wait->flags &= ~WQ_FLAG_EXCLUSIVE;spin_lock_irqsave(&q->lock, flags);if (list_empty(&wait->task_list))__add_wait_queue(q, wait);set_current_state(state);spin_unlock_irqrestore(&q->lock, flags);
}

接下来 Linux 就会选择下一个就绪状态的进程来执行。这就是阻塞原理的上半段，就是进程修改自己的状态，主动交出 CPU 的执行权。当有数据到达的时候，内核首先将数据包放到该 socket 的接收队列中。然后扫描一下 socket 等待队列，然后发现：“呦呵，有进程阻塞在这个 socket 上面哎，好唤醒它”。

具体到代码里就是 __wake_up_common 这个函数会访问 socket 的等待队列。

//file: kernel/sched/core.c
static void __wake_up_common(wait_queue_head_t *q, unsigned int mode,int nr_exclusive, int wake_flags, void *key)
{wait_queue_t *curr, *next;list_for_each_entry_safe(curr, next, &q->task_list, task_list) {unsigned flags = curr->flags;if (curr->func(curr, mode, wake_flags, key) &&(flags & WQ_FLAG_EXCLUSIVE) && !--nr_exclusive)break;}
}

在 __wake_up_common 中找出一个等待队列项 curr，然后调用其回调函数 curr->func，来完成进程的唤醒。不过，要注意的是，这个唤醒只是把相应的进程放到可运行队列里而已。真正的执行还得等其它进程主动释放 CPU 或者是时间片到了之后，内核把其它进程拿下以后才能真正获得 CPU 并开始执行。
参考：图解 | 深入理解高性能网络开发路上的绊脚石 - 同步阻塞网络 IO说到这里，你可能还会问了。内核是如何接收包的，毕竟唤醒用户进程是它干的。难道它不是一个死循环么？是的，并不是。网卡上收到数据包的时候，是通过硬中断唤醒内核进程处理，硬中断会触发软中断。有了软中断请求以后，ksoftirqd 内核线程才开始执行。来从网卡上取包，处理，放到接收队列，然后唤醒用户进程。
参见：图解Linux网络包接收过程
究其根源，是由网卡的硬中断来触发的。如果一段时间内没有网络包处理，那么没有死循环来消耗 CPU 的。对网络底层还有啥不理解的，来看看我的公众号「开发内功修炼」或许可以帮你解开一些困惑。

Github: GitHub - yanfeizhang/coder-kung-fu: 开发内功修炼
哦对了，想理解多路复用，来看看我的这一篇吧，也是从源码角度深入分析的。图解 | 深入揭秘 epoll 是如何实现 IO 多路复用的！