Repository navigation
Expose annotation to anonymous virtual memory ranges to mmap module #142419
Description
Activity
Since the underlying system call annotates an existing memory range, wouldn't it more natural for this to be a method call on the
mmapobject? E.g.mm = mmap.mmap(...); mm.set_name("foobar"). That way you could also change the name multiple times.I like the idea of a method. If prctl() fails, we can raise an exception. It allows ignoring the error in the caller. And it's easier to document that the method is only available on Linux 5.17 or newer.
Reacted by Donghee NaAnother option would be doing the same thing as with thread names: add this as a Python
nameproperty (that is allow theget_nameoperation as well as theset_name), and do a "best effort" to synchronize it with the OS.Another option would be doing the same thing as with thread names: add this as a Python name property (that is allow the get_name operation as well as the set_name), and do a "best effort" to synchronize it with the OS.
The threading module design requires to ignore silently errors which is not great :-(
threading.py:try: _set_name(self._name) except OSError: pass
Yeah, because in that model you primarily set the Python property. This can store any string losslessly, so it's the preferred way to get the name back; it also works the same on all platforms.
Syncing the OS-level annotation is then "just" for easier debugging. No guarantees there; data loss is expected -- full (incompatible OS) or partial (long strings, non-ASCII strings, embedded NULs, ...).I don't think reading the name back from the OS makes much sense. I don't think Linux requires that the entire mmapped range have the same name - so 3rd-party code could set one name for the first half, and another name for the second half.
It would also require parsing
/proc/<pid>/maps, which seems rather pricey for a property read.The threading module design requires to ignore silently errors which is not great :-(
Honestly, given that this is mainly intended for debugging, I don't see what else one would do with an error other than silently ignore it. This feature seems inherently best-effort.
Reacted by Petr ViktorinI don't think reading the name back from the OS makes much sense.
Yes. One of the nice things about the thread API is that you can get the name from the Python
Threadobject.
Feature or enhancement
Proposal:
Since the annotation of anonymous virtual memory ranges has landed
(c4ccaf4),
We can now consider exposing this feature to end users as well.
#141770 (comment)
@encukou proposed adding a name parameter to mmap.mmap, and I think this would be a great addition.
It would make debugging much easier by allowing people to identify and track individual mmap allocations.
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
#141770 (comment)
Linked PRs