linux - 在将数据从内核复制到用户期间，非阻塞I/O是否会进入休眠状态？

Question

我问这个问题是因为我正在使用Got来复用I/O，它使用了epollwait。

当套接字准备就绪时，goroutine将被唤醒并开始以非阻塞模式读取套接字。如果在将数据从内核复制到用户的过程中read系统调用仍然被阻止，那么我认为连接gorouine的内核线程也将进入休眠状态。

我不确定，如果我错了，希望有人可以帮助纠正我。

Answer 1

我无法完全解析您所写的内容。

我将尝试做出一个纯粹的猜测，并且您可能会忽略一个事实，即进入非阻塞模式的套接字上的write(2)和read(2)系统调用(以及它们类似的系统调用，例如send(2)和recv(2))可以免费使用(并且分别返回)的数据少于请求的数据。
换句话说，在非阻塞套接字上的write(2)调用被告知要写入1兆字节的数据，将消耗掉与关联的内核缓冲区中当前大小相同的数据，并立即返回，表示仅消耗了同样多的数据。下次直接调用write(2)可能会返回EWOULDBLOCK。
read(2)调用也是如此:如果向它传递一个足以容纳1兆字节数据的缓冲区，并告诉它读取该字节数，则该调用只会耗尽内核缓冲区的内容并立即返回，从而表明实际上复制了很多数据。下次直接调用read(2)可能会返回EWOULDBLOCK。

因此，任何将数据获取或放入套接字的尝试几乎都会立即成功:在将数据铲入内核缓冲区和用户空间之间之后，或者立即使用EAGAIN返回代码。

当然，在执行此类syscall的过程中，可能存在OS线程被挂起的可能性，但这不算作“阻塞syscall”。

响应OP的以下评论，将更新为原始答案:

<…>
This is what I see in book "UNIX Network Programming" (Volume 1, 3rd), chapter 6.2:

A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes. Using these definitions, the first four I/O models—blocking, nonblocking, I/O multiplexing, and signal-driven I/O—are all synchronous because the actual I/O operation (recvfrom) blocks the process.

它使用“块”来描述非阻塞I/O操作。这让我感到困惑。
我仍然不理解为什么如果实际上没有阻止该过程，那么本书为什么使用“阻止该过程”。

我只能猜测，这本书的作者打算强调指出，自从进入syscall并从其返回之前，该过程确实被阻塞。对非阻塞套接字的读写会阻塞以在内核和用户空间之间传输数据(如果可用)。我们口语地说这不会阻止，因为我们的意思是“它不会阻止等待并在不确定的时间内不执行任何操作”。

该书的作者可能将此与所谓的异步I/O(在Windows™上称为“重叠”)进行对比，在异步I/O中，您基本上为内核提供了一个用于/用于数据的缓冲区，并要求它完全与您的内核并行处理。代码-从某种意义上讲，相关的syscall立即返回，并且I/O在后台执行(关于您的用户空间代码)。
据我所知，Go在它所支持的平台上都没有使用内核的异步I/O工具。对于Linux及其现代 there的发展，您可能会喜欢 io_uring subsystem。

哦，还有一点。这本书可能(至少到那时为止是在叙述中)正在讨论一种简化的“经典”方案，其中没有进程内线程，并且并发的唯一单元是进程(具有单个执行线程)。在此方案中，任何系统调用显然都会阻塞整个过程。相比之下，Go仅在支持线程的内核上工作，因此在Go程序中，系统调用永远不会阻塞整个进程，而只会阻塞被调用的线程。

让我再一次尝试解释问题，正如我所知，OP指出了这一点。

服务多个客户端请求的问题并不是新问题，它最明显的第一条陈述就是 "The C10k problem"。
为了快速重述，在其管理的套接字上具有阻塞操作的单线程服务器实际上只能一次处理一个客户端。
为了解决这个问题，有两种简单的方法:

派生服务器进程的副本以处理每个传入的客户端连接。

在支持线程的操作系统上，在同一进程内派生一个新线程来处理每个传入的客户端。

它们各有利弊，但都在资源使用方面很糟糕，而且(更重要的是)它们不能很好地与大多数客户端在处理方面执行的I/O速率和带宽相对较低的事实打交道。典型服务器上可用的资源。
换句话说，当与客户端进行典型的TCP/IP交换时，服务线程大部分时间都处于客户端套接字上的 write(2)和 read(2)调用中。
这就是大多数人在谈论套接字上的“阻塞操作”时的意思:如果套接字正在阻塞，并且对该套接字的操作将一直阻塞直到可以实际执行，并且始发线程将进入休眠状态并不确定的数量。时间。

另一个需要注意的重要事项是，当套接字准备就绪时，与唤醒之间的 sleep 时间相比，完成的工作量通常很小。
胎面 sleep 时，其资源(例如内存)被有效地浪费了，因为它们不能用于执行任何其他工作。

输入“轮询”。它注意到网络套接字的就绪点相对稀少且介于两者之间，从而解决了资源浪费的问题，因此，有很多这样的套接字由单个线程提供服务是有意义的:它允许将线程保持为在理论上尽可能地忙，并且还允许在需要时进行扩展:如果单个线程无法处理数据流，请添加另一个线程，依此类推。

这种方法肯定很酷，但是它有一个缺点:读取和写入数据的代码必须重新编写以使用回调样式，而不是原始的普通顺序样式。用回调编写是很难的:您通常必须实现复杂的缓冲区管理和状态机来处理此问题。
Go运行时通过为其执行流单元添加另一层调度来解决此问题，即goroutines:对于goroutine，套接字上的操作始终处于阻塞状态，但是当goroutine即将在套接字上进行阻塞时，这仅通过挂起进行透明处理goroutine本身-直到请求的操作将能够继续进行-并使用goroutine正在运行的线程来执行其他工作¹。
这样可以兼具两种方法的优点:程序员可以编写经典的无脑顺序无回调的网络代码，但是用于处理网络请求的线程已被充分利用²。

至于最初的阻塞问题，当套接字上的数据传输发生时，goroutine及其运行的线程确实都被阻塞了，但是由于发生的是内核与用户空间缓冲区之间的数据交换，因此延迟是在大多数情况下，它很小，并且与经典的“轮询”情况没有什么不同。

请注意，在Go中执行系统调用(包括在非轮询描述符上进行I/O)(直到发布并包括Go 1.14)确实会阻止调用goroutine及其运行的线程，但处理方式与pollable有所不同描述符:当一个特殊的监视线程注意到在某个系统调用中花费的goroutine超过一定时间(20 µs，IIRC)时，运行时就会从下方拉出所谓的“处理器”(在OS线程上运行goroutine的运行时事物) gorotuine并尝试使其在另一个OS线程上运行另一个goroutine；如果有一个想运行的goroutine，但没有空闲的OS线程，则Go运行时会创建另一个。
因此，“正常”阻塞I/O仍然在Go中处于两种阻塞状态:它同时阻塞goroutine和OS线程，但是Go调度程序可确保整个程序仍然能够取得进展。

对于使用内核提供的真正异步I/O来说，这可以说是一个完美的案例，但是还不存在。

¹有关更多信息，请参见 this classic essay。

²Go运行时肯定不是第一个倡导此想法的人。例如，看看 the State Threads library(以及最近的 libtask )，它们在普通C语言中实现了相同的方法。 ST库中有出色的文档，可以解释这个想法。