Or if anyone can give a credible explanation why my preadv() emulation is based on some flawed assumptions, perhaps I should just remove it and default to coalescing buffers instead. It would probably make sense to still make the coalesce option available, and override the preadv() emulation on windows. So like torrents from folder 1 are stored in folder A, folder 2 in folder B and so on. I want something like qbittorrent where you can load torrents from multiple folders to multiple respective download folders. The reason why coalesce_reads and coalesce_writes don't do anything is because currently those options are only available for system that don't have preadv() and pwritev() (which I pretend windows does). Better watch folder options - In 2.2.1, I can automatically load torrents from 1 folder, and that folder is the current download folder. Now, whether the kernel actually merge them or not, I don't think we can tell from process monitor, can we? My impression is that process monitor intercepts library calls, not kernel calls or actual I/O calls.ĭo you feel confident that the fact that these operations appear as individual rows in process monitor is indicative of a problem? I then wait for all operations to complete. This should let the lower layer merge them, just like normal kernels do. Which issues all reads (or writes) as overlapped (asynchronous) operations, in order, back-to-back. So, after having looked into this a bit, I'm pretty confident the vast majority of those reads (at least the ones whose offset are back-to-back) are part of my pwritev() emulation.
0 kommentar(er)
