[coro_io] Allow multiple random_coro_file instances to share a single file descriptor

[sqrtpineapple]

Search before asking

• I searched the issues and found no similar issues.

What happened + What you expected to happen

In our searcher workload, we create multiple random_coro_file instances for the same physical file to perform concurrent random reads across different executors or I/O contexts.

Currently, every path-based random_coro_file opens the file independently and consumes one file descriptor. Therefore, FD usage grows approximately as:

number of files × random_coro_file instances per file

For example:

10 files × 32 random_coro_file instances per file = 320 file descriptors

A searcher pod may contain many files and concurrent readers. The resulting FD usage can exceed the pod's ulimit -n, causing open() to fail with EMFILE (Too many open files). This may also prevent the process from opening unrelated files or sockets.

I expect random_coro_file to support multiple instances sharing one existing file descriptor, especially for positioned operations such as async_read_at.

The desired behavior is:

• Open each physical file only once.
• Allow multiple random_coro_file instances to use the same fd concurrently.
• Support non-owning fd semantics so destroying one wrapper does not close the shared fd.
• Keep the fd valid until all wrappers and in-flight operations have completed.
• Preserve the existing path-based API and behavior.

With this model, FD usage becomes proportional to the number of physical files instead of the number of random_coro_file instances.

Reproduction way

Create multiple random_coro_file instances for the same file:

std::vector<std::unique_ptr<coro_io::random_coro_file>> files;

for (std::size_t i = 0; i < concurrency; ++i) {
  files.emplace_back(std::make_unique<coro_io::random_coro_file>(
      "/path/to/data", std::ios::in, executor));
}

Keep the process running and inspect its descriptors:

ls -l /proc/<pid>/fd

When concurrency is 320, approximately 320 descriptors refer to the same file.

In a deployment with a sufficiently low FD limit, increasing the number of files or readers eventually causes:

open: Too many open files

Expected result after adding fd sharing:

10 physical files × 32 wrappers per file
Current:  320 file descriptors
Expected: 10 file descriptors

All wrappers should still be able to perform concurrent async_read_at operations correctly.

Anything else

A possible solution is to add constructors that accept an existing fd and explicitly define its ownership:

random_coro_file(
    int fd,
    asio::io_context::executor_type executor,
    std::string_view file_path = "",
    bool own_fd = true);

When own_fd is false:

• The wrapper should use the supplied fd without calling open() or dup().
• close() and the destructor should detach or release the native handle without closing it.
• The caller is responsible for keeping the fd alive until all wrappers and in-flight I/O operations have completed.

The implementation should cover both the thread-pool pread/pwrite backend and the native asynchronous backend where supported.

I have implemented a prototype and added ownership, lifecycle, concurrency, and native-handle tests.

I also ran a multi-file benchmark with 10 files, 32 wrappers per file, 320 concurrent 4 KiB direct random-read coroutines, and the Linux io_uring backend.

Mode	FDs per file	Total file FDs	Median IOPS (32 I/O threads)
Shared fd	1	10	3,653,516
Duplicated fd	33	330	3,669,355
Path-based open	32	320	3,686,683

The maximum throughput difference was about 0.9%, while shared-fd mode reduced the file descriptor count from 320 to 10. All benchmark runs completed with zero I/O errors.

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

[qicosmos]

欢迎贡献PR，需要注意几个问题：
需要重点处理三个问题：

1. bool own_fd 语义不够安全
   “借用 FD”无法保证生命周期。调用者提前关闭 FD 后，描述符数字甚至可能被系统复用，后续请求可能误读另一个文件。更稳妥的是提供带引用计数的shared_file_handle，而不是裸 int + bool。

2. issue 中的生命周期要求存在矛盾
   前面要求“FD 保持有效，直到所有 wrapper 和在途 I/O 完成”，后面又规定非拥有模式由调用者负责生命周期。二者应明确选择。

3. 当前线程池实现还要避免捕获 this，后台任务通过this 访问 prw_random_file_。如果 wrapper 在 I/O 完成前被销毁或关闭，会产生生命周期风险。任务应直接按值捕获共享的文件句柄状态。

[sqrtpineapple]

@qicosmos 感谢建议，我重新调整了实现方案。现在不再使用 int fd + bool own_fd，而是新增了通过引用计数管理 fd 的 shared_file_handle。random_coro_file 会持有这个 handle，调用方在构造完成后可以释放自己的引用；只要仍有 wrapper 或在途 I/O，fd 就会保持有效，最后一个引用释放时才会真正关闭。这样文件生命周期由 yalantinglibs 统一管理，不再依赖调用方保证借用 fd 的有效性。

线程池路径也做了调整。提交到线程池的任务不再捕获 this，而是按值捕获 shared_ptr<file_state>，并通过其中的 shared_file_handle 访问 fd。因此即使 wrapper 在 I/O 完成前被关闭或析构，后台任务持有的文件状态仍然有效。

另外，为了避免调用方通过 Asio 对象直接关闭共享 fd，我移除了 basic_random_coro_file::get_async_stream_file()。目前也补充了共享 fd、wrapper 生命周期、在途 I/O 和 fd 复用等相关测试。接下来我会基于这个方案整理并提交 PR，再请帮忙 review，谢谢！