classification
Title: mmap.flush() issue msync() even if mapping was created with prot=mmap.PROT_READ only
Type: Stage:
Components: Versions:
process
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: Nosy List: neologix, r.david.murray, socketpair
Priority: normal Keywords:

Created on 2011-01-08 12:20 by socketpair, last changed 2011-02-21 05:41 by socketpair. This issue is now closed.

Messages (7)
msg125780 - (view) Author: Марк Коренберг (socketpair) * Date: 2011-01-08 12:20
python mmap objects issue msync() in destructor even if mapping was created with  prot=mmap.PROT_READ only
msg125781 - (view) Author: Марк Коренберг (socketpair) * Date: 2011-01-08 12:34
Soory, this is dup of Issue2643
msg125782 - (view) Author: Марк Коренберг (socketpair) * Date: 2011-01-08 12:36
i'm crazy today. sorry twice. this is not dup of 2643 :(
msg125785 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-01-08 16:02
> 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.
msg125790 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-01-08 16:27
Antoine didn't want to backport that patch.  Does the fix applied in issue 678250 address this?
msg125798 - (view) Author: Марк Коренберг (socketpair) * Date: 2011-01-08 20:12
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.
msg125803 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-01-08 23:28
>  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...
History
Date User Action Args
2011-02-21 05:41:19socketpairsetstatus: open -> closed
resolution: duplicate
2011-01-08 23:28:21neologixsetmessages: + msg125803
2011-01-08 20:12:30socketpairsetmessages: + msg125798
title: python mmap objects issue msync() in destructor even if mapping was created with prot=mmap.PROT_READ only -> mmap.flush() issue msync() even if mapping was created with prot=mmap.PROT_READ only
2011-01-08 16:27:44r.david.murraysetnosy: + r.david.murray
messages: + msg125790
2011-01-08 16:02:47neologixsetnosy: + neologix
messages: + msg125785
2011-01-08 12:36:01socketpairsetmessages: + msg125782
2011-01-08 12:34:25socketpairsetmessages: + msg125781
2011-01-08 12:20:25socketpaircreate