mmap.flush() issue msync() even if mapping was created with prot=mmap.PROT_READ only

[01e27b45-90f2-4c74-9e5e-7e7e54c3d78e]

BPO	10867
Nosy	@bitdancer, @socketpair

^{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: ```python assignee = None closed_at = created_at = labels = [] title = 'mmap.flush() issue msync() even if mapping was created with prot=mmap.PROT_READ only' updated_at = user = 'https://github.com/socketpair' ``` bugs.python.org fields: ```python activity = actor = 'socketpair' assignee = 'none' closed = True closed_date = closer = 'socketpair' components = [] creation = creator = 'socketpair' dependencies = [] files = [] hgrepos = [] issue_num = 10867 keywords = [] message_count = 7.0 messages = ['125780', '125781', '125782', '125785', '125790', '125798', '125803'] nosy_count = 3.0 nosy_names = ['r.david.murray', 'neologix', 'socketpair'] pr_nums = [] priority = 'normal' resolution = 'duplicate' stage = None status = 'closed' superseder = None type = None url = 'https://bugs.python.org/issue10867' versions = [] ```

[01e27b45-90f2-4c74-9e5e-7e7e54c3d78e]

python mmap objects issue msync() in destructor even if mapping was created with prot=mmap.PROT_READ only

[01e27b45-90f2-4c74-9e5e-7e7e54c3d78e]

Soory, this is dup of bpo-2643

[01e27b45-90f2-4c74-9e5e-7e7e54c3d78e]

i'm crazy today. sorry twice. this is not dup of 2643 :(

[79528080-9d85-4d18-8a2a-8b1f07640dd7]

python mmap objects issue msync() in destructor even if mapping was created with prot=mmap.PROT_READ only

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.

[bitdancer]

Antoine didn't want to backport that patch. Does the fix applied in bpo-678250 address this?

[01e27b45-90f2-4c74-9e5e-7e7e54c3d78e]

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.

[79528080-9d85-4d18-8a2a-8b1f07640dd7]

have changed title of the bug. This is more precisely describe the problem

Yes, its's not quite the same problem.

I think, that flush() should be no-op if mapping is read-only.

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...