New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mmap.flush() issue msync() even if mapping was created with prot=mmap.PROT_READ only #55076
Comments
python mmap objects issue msync() in destructor even if mapping was created with prot=mmap.PROT_READ only |
Soory, this is dup of bpo-2643 |
i'm crazy today. sorry twice. this is not dup of 2643 :( |
Actually, the call to msync(2) from destructor has been removed altogether in py3k. See http://bugs.python.org/issue2643. The patch (one line) might be worth backporting, though. |
Antoine didn't want to backport that patch. Does the fix applied in bpo-678250 address this? |
I have changed title of the bug. This is more precisely describe the problem. In my code, I do mmap.close(), so msync does not called. Generally, calling msync() on read-only mapping is not needed at all. And meven more, calling msync() on memory-mapped USB-camera will lead to EIO errno I think, that flush() should be no-op if mapping is read-only. |
Yes, its's not quite the same problem.
This has already be done for py3k. See http://svn.python.org/view/python/branches/py3k/Modules/mmapmodule.c?r1=84950&r2=85678 Note that you shouldn't be calling flush in the first place... |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: