Skip to content
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

Closed
socketpair mannequin opened this issue Jan 8, 2011 · 7 comments
Closed

Comments

@socketpair
Copy link
Mannequin

socketpair mannequin commented Jan 8, 2011

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:

assignee = None
closed_at = <Date 2011-02-21.05:41:19.216>
created_at = <Date 2011-01-08.12:20:25.991>
labels = []
title = 'mmap.flush() issue msync() even if mapping was created with  prot=mmap.PROT_READ only'
updated_at = <Date 2011-02-21.05:41:19.216>
user = 'https://github.com/socketpair'

bugs.python.org fields:

activity = <Date 2011-02-21.05:41:19.216>
actor = 'socketpair'
assignee = 'none'
closed = True
closed_date = <Date 2011-02-21.05:41:19.216>
closer = 'socketpair'
components = []
creation = <Date 2011-01-08.12:20:25.991>
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 = []

@socketpair
Copy link
Mannequin Author

socketpair mannequin commented Jan 8, 2011

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

@socketpair
Copy link
Mannequin Author

socketpair mannequin commented Jan 8, 2011

Soory, this is dup of bpo-2643

@socketpair
Copy link
Mannequin Author

socketpair mannequin commented Jan 8, 2011

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

@neologix
Copy link
Mannequin

neologix mannequin commented Jan 8, 2011

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
Copy link
Member

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

@socketpair
Copy link
Mannequin Author

socketpair mannequin commented Jan 8, 2011

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.

@socketpair socketpair mannequin changed the 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 Jan 8, 2011
@neologix
Copy link
Mannequin

neologix mannequin commented Jan 8, 2011

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

@socketpair socketpair mannequin closed this as completed Feb 21, 2011
@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant