目前 acl fiber 里的 io 可以同时使用网络 io 和文件 io，内部会自动判断 io 句柄的类型，针对网络句柄，会通过 epoll 等事件引擎监控，针对文件句柄，直接进行 io 读写。

"针对文件句柄，直接进行 io 读写" 是不是意味着针对文件句柄时， fiber实际上是会被block住的，我的理解是在通过epoll对网络句柄状态进行监控的时候， fiber会被调度让出，线程(CPU)资源会给到其他fiber使用，而在文件句柄上，因为缺少epoll这一层，会是直接的一个block io.

acl 的协程调度过程是单线程方式，但你可以通过调用 go_wait_thread[&] {} 将文件 IO 放到独立线程中去运行。

好的， 我去了解下go_wait_thread， 谢谢！

我看go_wait_thread的实现 ( https://github.com/acl-dev/acl/blob/master/lib_fiber/cpp/include/fiber/go_fiber.hpp#L54-L65 )，会是每次提交lamda时，都创建并启动一个新到的线程来执行，这样多次提交的开销会比较大，是不是不可能构建一个thread pool，让go_wait_thread提交的lambda在thread pool上执行，尽量避免资源分配的开销，进而提升性能？

这个建议不错，将来会考虑将 acl 中的线程库模块用上。

期待！ 你指的线程库模块，是指的 https://github.com/acl-dev/acl/blob/master/lib_acl/src/thread/acl_pthread_pool.c 这一部分么？ 我看目前只有c的实现， 好像没有c 的封装？

https://github.com/acl-dev/acl/blob/master/lib_acl_cpp/src/stdlib/thread_pool.cpp

谢谢！

目前 acl 协程已经支持了 io_uring，这样可以同时支持文件IO和网络IO了，因为针对文件的操作（比如：open/read/write/unlink/mkdir 等）都由 io_uring 异步处理，而不会阻塞协程调度器了。经过测试，当磁盘IO 100%时，只有内核中的 kworker flush 进程会出现 D 状态，而协程调度器是不受影响的。

@zhengshuxin fiber io_uring对liburing的版本有要求么？ 我在ubuntu 22.04上apt install liburing-dev/或者直接用最新的liburing源码编译之后，在samples (export HAS_IO_URING=yes）的时候，会报link错误：

/xxx/acl/lib_fiber/c/src/event/event_io_uring.c:249: undefined reference to `io_uring_prep_unlink'

nm查看liburing.so，的确没有暴露io_uring_prep_unlink，想确认下acl使用的liburing版本 （liburing 2.2分支也还是没有暴露io_uring_prep_unlink）

io_uring_prep_unlink接口暴露在liburing-ffi ( axboe/liburing#563 )中：

nm -gC liburing-ffi.so | grep io_uring_prep_unlink
00000000000061e0 T io_uring_prep_unlink
00000000000061a0 T io_uring_prep_unlinkat

已提交 #312 进行修复

这个liburing-ffi.so是怎么编译出来的？我是直接从官方的github下载源码编译后使用的，是包含那两个函数的。

liburing 2.4分支./configure && make && make install 编出来的，目前master分支应该也有，现在make出来会有liburing.so和liburing-ffi.so同时生成出来： https://github.com/axboe/liburing/blob/master/src/Makefile#L23-L29

其中liburing-ffi.so中会会包括prep_unlink接口 ( https://github.com/axboe/liburing/blob/master/src/liburing-ffi.map#L126 )

Ok, thanks!
--zsx