fantix

@mayli 我大概明白了，正如你说的，我也觉得应该是可以优化的[1]，或者将来可以[2]，就是可能写起来比较费劲。另外，作为抽象化的库，kLoop 我认为可以从两方面做批量优化：1 、单次主循环内批量操作：当 I/O 请求比较密集的时候，一次循环有机会批量提交处理几十上百个请求，每个请求可能都是由多个 SQE 链接实现，这样一次循环就能省几百 syscall ； 2 、提高抽象层级，直接做 HTTP 静态文件服务器[狗头]。以上还都是臆想，有待实现验证测评。

[1]: https://lwn.net/Articles/863071/
[2]: https://lwn.net/Articles/847951/

@mayli 好像可以创建一对 pipe ，先把 header 写进去，然后提交两个 splice(2) 任务（无须 link ？），一个连文件另一个连 socket 。这个不是 asyncio 层面的，但类似于计划中 kLoop 的 `loop.sendfile()` 实现，还没试过，希望能帮上忙。

@haoliang 感谢夸奖！ trio 是好东西，异常扔得特别干净

@14 嗯惭愧……那个 PR 确实拖了好几年才做完……

@mayli 感谢分享！我赞同您提到的三点：1 、直接使用 io_uring 或者甚至是包装过的 liburing 来做业务逻辑，编程体验并不直观； 2 、深度利用队列需要一定技巧，比如可能需要在 SQ 提交之前修改顺序，才能将需要链接的元素排在一起，因为目前链接功能只能把挨在一起的几个元素连起来； 3 、io_uring 并不提供流量控制功能，需要调用者自己搞。

需要为其他读到这里的同学澄清的是，这些在 kLoop 中属于实现细节，参与开发的同学确实需要面对底层接口的复杂性，以及处理好各种接口异常，比如用发送队列做重试以提供高阶流量控制等等；然而，对于 kLoop 使用者而言，这些复杂性应该是封装在统一的 asyncio 接口之下的，比如用户只需调用 `loop.sendfile()`，而不需要考虑这个操作实际上可能链接了多个 io_uring 任务，包括创建管道、两次 splice 来连接文件和网络，以及流量控制所需要的重试（还没实现，大致猜测），以最高效的方式利用 io_uring 来完成任务。

@lixile draw.io ，好像现在叫 diagrams.net ，可以脱机当本地应用使

有幸在本书成书后的开发阶段抢先阅读过，非常认同“基础编程素养”和“编程理念”的部分，结合案例讲技巧，非常值得收藏。