Replies: 1 comment
-
Yes, there are several ways you could potentially run into deadlocks if your implementation introduces potential scenarios with memory mapped files backed by something that also relies on memory mapped files. In general, page-in and page-out I/O paths that read in and flush out pages to and from memory mapped files cannot safely block on memory mapped I/O. Your best option here is probably to keep the cache file open, use flags for non cached operation when you open it, and read and write to it, but not memory map it. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I made a readonly file system that accesses remote storage and has a local cache implemented as a memory-mapped file that contains 16KiB blocks already downloaded from the remote.
Now when data is in cache,
ReadFile
simply tries to copy bytes from the memory-mapped cache file that is stored on ordinary physical disk.Unfortunately, I hit a scenario where this read seems to take an enormous amount of time (~20 minutes) for a 16KiB block from an NVMe SSD, which hints at some kind of dead/live locking.
Could this issue somehow be caused by reentry into system memory mapping/paging mechanism? E.g. system tries to read a mmapped block from my virtual FS, and my virtual FS gets stuck because it tries to read a mmaped block from physical drive in order to satisfy the request?
When this happens, Task Manager and procmon both freeze.
P.S. If this is a case, is there another way to read blocks of file on demand concurrently without having to open/close it all the time, and preferably, keeping it inaccessible to other programs?
Beta Was this translation helpful? Give feedback.
All reactions