This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients eryksun, paul.moore, steve.dower, tim.golden, zach.ware
Date 2020-06-05.22:47:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1591397225.82.0.932982465865.issue40882@roundup.psfhosted.org>
In-reply-to
Content
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.

_winapi.UnmapViewOfFile needs to be implemented. Then the temporary view can be unmapped as follows:

    self._name = name
    h_map = _winapi.OpenFileMapping(_winapi.FILE_MAP_READ, False, name)
    try:
        p_buf = _winapi.MapViewOfFile(h_map, _winapi.FILE_MAP_READ, 0, 0, 0)
    finally:
        _winapi.CloseHandle(h_map)
    try:
        size = _winapi.VirtualQuerySize(p_buf)
    finally:
        _winapi.UnmapViewOfFile(p_buf)
    self._mmap = mmap.mmap(-1, size, tagname=name)

[1]: https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-unmapviewoffile
History
Date User Action Args
2020-06-05 22:47:05eryksunsetrecipients: + eryksun, paul.moore, tim.golden, zach.ware, steve.dower
2020-06-05 22:47:05eryksunsetmessageid: <1591397225.82.0.932982465865.issue40882@roundup.psfhosted.org>
2020-06-05 22:47:05eryksunlinkissue40882 messages
2020-06-05 22:47:05eryksuncreate