[issue34321] mmap.mmap() should not necessarily clone the file descriptor

2021-04-15 Thread Zackery Spytz
Change by Zackery Spytz : -- keywords: +patch nosy: +ZackerySpytz nosy_count: 3.0 -> 4.0 pull_requests: +24159 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25425 ___ Python tracker

[issue34321] mmap.mmap() should not necessarily clone the file descriptor

2021-01-31 Thread Christian Heimes
Christian Heimes added the comment: This issue came up in another discussion. I have given it some thought. mmap.mmap() dups the FD because its close() and __exit__() methods close(2) the fd. The size() and resize() methods use the fd to determine the size of the underlying file or to resize

[issue34321] mmap.mmap() should not necessarily clone the file descriptor

2021-01-30 Thread Christian Heimes
Change by Christian Heimes : -- nosy: +christian.heimes versions: +Python 3.10 -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker ___ _

[issue34321] mmap.mmap() should not necessarily clone the file descriptor

2018-08-03 Thread Josh Rosenberg
Josh Rosenberg added the comment: Why would it "cause an issue if the file is closed before accessing the mmapped region"? As shown in your own link, the constructor performs the mmap call immediately after the descriptor is duplicated, with the GIL held; any race condition that could close

[issue34321] mmap.mmap() should not necessarily clone the file descriptor

2018-08-02 Thread Manuel
New submission from Manuel : mmap.mmap(fileno, length, flags, prot, access, offset) always clones the file descriptor that should be used [1]. The cloning of the file descriptor seems to be done to ensure that the file cannot be closed behind mmap's back, but if you are mmap()'ing a lot of me