You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
mmap.mmap in Windows doesn't support an exist_ok parameter and doesn't correctly handle the combination fileno=-1, length=0, and tagname with an existing file mapping. SharedMemory has to work around these limitations.
Part of the workaround for the create=False case requires mapping a view via MapViewOfFile in order to get the size from VirtualQuerySize, since mmap.mmap requires it (needlessly if implemented right) when fileno=-1. This mapped view never gets unmapped, which means the shared memory will never be freed until the termination of all processes that have opened it with create=False. Also, at least in a 32-bit process, this wastes precious address space.
UnmapViewOfFile needs to be implemented in the _winapi module. Then the temporary view can be unmapped as follows:
Thanks for working on the PR, Zackery. Would you be interested in working on improvements to mmap for 3.10? With support in mmap, the Windows-specific initialization of SharedMemory could be as simple as the following:
The new mmap create parameter would default to None, which uses the current behavior that allows either opening or creating a file mapping with no sanity checking (e.g. a valid fd gets passed in, but it opens an unrelated file mapping via tagname). If create is true, and there's an existing file mapping named tagname, then raise FileExistsError. If create is false, call OpenFileMappingW instead of CreateFileMappingW. In this case, fileno must be -1, length is allowed to be 0, and tagname must be a non-empty string. If length is 0, map the entire file mapping and get the size via VirtualQuery: RegionSize.