Many C APIs that weren't written with Zig's Io interface in mind let the library user do asynchronous/concurrent programming by giving them a file descriptor to wait on.
Notably, the user does not read/write to the file, they only wait for a status change. When a file is ready to be read, the user calls a library function that dispatches the actual read() call.
Some examples of this design include libwayland-client:
const fd = dpy.getFd();poll(fd, POLLIN | POLLOUT);dpy.readEvents(); // This is where read() is calleddpy.dispatchPending();
or Vulkan:
const fd = exportFenceFd(fence);poll(fd, POLLIN);importFenceFd(fence, fd);waitForFences(&.{fence});
Currently, it seems like there is no way to purely call poll() with Zig's Io interface, you can only batch read()/write() requests that may (or don't) use poll() in the background.
Many C APIs that weren't written with Zig's `Io` interface in mind let the library user do asynchronous/concurrent programming by giving them a file descriptor to wait on.
Notably, the user *does not* read/write to the file, they only wait for a status change. When a file is ready to be read, the user calls a library function that dispatches the actual `read()` call.
Some examples of this design include libwayland-client:
1. `const fd = dpy.getFd();`
2. `poll(fd, POLLIN | POLLOUT);`
3. `dpy.readEvents(); // This is where read() is called`
4. `dpy.dispatchPending();`
or Vulkan:
1. `const fd = exportFenceFd(fence);`
2. `poll(fd, POLLIN);`
3. `importFenceFd(fence, fd);`
4. `waitForFences(&.{fence});`
Currently, it seems like there is no way to purely call `poll()` with Zig's `Io` interface, you can only batch `read()`/`write()` requests that may (or don't) use `poll()` in the background.