linux - 为什么使用Tokio进行异步网络IO的Rust项目为什么要对文件描述符5进行数千次写入？

Question

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

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

mio(作为tokio实现的一部分)使用这些写操作来唤醒epoll_wait syscall中的工作线程，而这些工作线程被文件描述符触发器以外的其他事物唤醒时。由于线程是在OS上通过syscall阻塞的，因此需要某种syscall来告诉OS取消阻塞线程。这可能是由 channel 引起的。如果您看到此消息，则表明您有闲置的工作人员。使用此syscall的替代方法是将这些线程保持在轮询繁忙等待中(在syscall和CPU时间上要昂贵得多)，或者只是根本不使用工作线程，直到它们被外部I/O唤醒(限制您的并发性)为止。我建议您查看这些影响实际上是对性能的影响，还是由应用程序中其他地方的瓶颈引起的。