为什么Rust项目使用Tokio进行异步网络IO时会有数千次写入文件描述符5？

Question

我正在使用strace分析我的代码以进行系统调用。我发现了一些令人惊讶的结果。跟踪显示，在进行200Mb数据的网络传输时，对文件描述符5进行了47254次单字节写入。

write(5, "\1", 1)

这段文字是什么意思？什么是fd 5？它可能来自哪里？有没有办法找出答案？

我对Linux的基础知识不是很了解。

ls -lrt /proc/24393/fd的输出

lrwx------ 1 95th 95th 64 Mar  1 20:56 9 -> 'socket:[97676]'
lr-x------ 1 95th 95th 64 Mar  1 20:56 7 -> /dev/random
lr-x------ 1 95th 95th 64 Mar  1 20:56 6 -> /dev/urandom
l-wx------ 1 95th 95th 64 Mar  1 20:56 5 -> 'pipe:[98345]'
lr-x------ 1 95th 95th 64 Mar  1 20:56 4 -> 'pipe:[98345]'
lrwx------ 1 95th 95th 64 Mar  1 20:56 3 -> 'anon_inode:[eventpoll]'
lrwx------ 1 95th 95th 64 Mar  1 20:56 2 -> /dev/pts/0
lrwx------ 1 95th 95th 64 Mar  1 20:56 1 -> /dev/pts/0
lrwx------ 1 95th 95th 64 Mar  1 20:56 0 -> /dev/pts/0

我检查了那个管道是什么(尽管这没有太大帮助)：

/proc/24393/fd$ lsof | grep 98345
btrs      24393       95th    4r     FIFO               0,11       0t0            98345 pipe
btrs      24393       95th    5w     FIFO               0,11       0t0            98345 pipe
tokio-run 24393 24394 95th    4r     FIFO               0,11       0t0            98345 pipe
tokio-run 24393 24394 95th    5w     FIFO               0,11       0t0            98345 pipe
tokio-run 24393 24395 95th    4r     FIFO               0,11       0t0            98345 pipe
tokio-run 24393 24395 95th    5w     FIFO               0,11       0t0            98345 pipe

Answer 1

当epoll_wait系统调用中的工作线程被文件描述符触发器以外的其他触发器唤醒时，mio (作为tokio实现的一部分)使用这些写操作来唤醒它们。由于线程在系统调用的操作系统中被阻塞，这需要某种类型的系统调用来告诉操作系统取消阻塞它们。这可能是由通道引起的。如果您看到这一点，那么这将表明您有空闲的工人。使用此syscall的替代方法是让这些线程处于轮询忙碌等待状态(在syscall和CPU时间上的开销要大得多)，或者根本不使用工作线程，直到它们被外部I/O唤醒(限制并发)。我建议您查看这些问题是实际的性能影响，还是由应用程序中其他地方的瓶颈造成的。