There may be others - I dont keep track of everything the engineers fix. 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. I dont know of any vulnerabilities off the top of my head, besides sending all kinds of crafted DHT responses.
It would probably make sense to still make the coalesce option available, and override the preadv() emulation on windows.
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). 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. 15 Im using uTorrent 3.1.3 and Im getting the error 'Disk Overloaded 100' after the download speed reaches 4-5 mb/s. 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)
