Store inode when reading /proc/*/smaps in _pslinux.py/get_memory_maps()

[GoogleCodeExporter]

At the moment, the function get_memory_maps() in the Linux implementation 
_pslinux.py, correctly parses the content of /proc/<pid>/smaps and stores some 
of the memory maps data in a container.

Unfortunately, it does not store the inode, although it is correctly parsed 
from first_line.

This is specifically necessary with SYSV00000000 maps, because their path names 
are not unique.

It would be great to store the inode as a new item in the returned container. 
It does not imply changes to existing applications.

On the other hand, I do not know how this can be emulated on other operating 
systems.

Original issue reported on code.google.com by remi.cha...@gmail.com on 20 Nov 2013 at 11:12

[GoogleCodeExporter]

I doubt this can be emulated on most operating systems.
By "path names not unique" you mean the path name is the same for different 
entries and you would like to differentiate them? Is that your use case?
If that's the case can't you just use the address ('addr')?

Original comment by g.rodola on 20 Nov 2013 at 11:23

[GoogleCodeExporter]

Exactly, I need to differentiate the anonymous ("SYSV00000000") shared memory 
blocks.

In the use case you described, it is definitively necessary because I need to 
detect related processes, which share an unique memory segment (And are 
therefore part of the same logical application).

The mapped address is not unique because different processes can map the same 
shared memory segment at different addresses in their address space.

On the other hand, the inode really represent the shared memory segment: It is 
equivalent to the shmid returned by the command ipcs.

I guess there is something very similar on all Unices, BSD etc... On Windows, 
there is probably an unique integer id which could serve the same purpose.

Thanks

Original comment by remi.cha...@gmail.com on 20 Nov 2013 at 11:48

[GoogleCodeExporter]

...but what would you do after you can differentiate between unique memory 
mappings?
I'm not sure I'm understanding your use case, I'm sorry (maybe some pseudo come 
could help?).

Generally speaking, if the use case is not common enough and the feature is not 
portable across many platform I usually decide not to add it. My impression so 
far is that this is the case (but again: I'm probably misinterpreting the use 
case).

Original comment by g.rodola on 20 Nov 2013 at 6:31

[GoogleCodeExporter]

One of the use of shared memory segments is to have different processes 
communicating with each other. For this, they need to map the segment in their 
memory space, using the unique shared id, called "shmid" by the command "ipcs".

The pathname of the shared memory segment is usable only if this is a file 
mapped into memory, but this is a special case (Most read-only files mapped in 
memory for ease of access). For interprocess communication, memory segments are 
defined by their shmid (Equivalent to an inode), not by their path names which 
is non-existent (Or given a default value): They are anonymous.

In other words, memory segments used in interprocess communications cannot be 
used without their id (That is, the inode as returned by the /proc file 
system), simply because they cannot be identified. Internally, Linux does not 
use the pathname, but of course the inode.

For example, these ids are necessary to check if two different applications are 
communicating via shared memory segments: This technology is widely used (I can 
give specific example by email, if necessary).

It would make sense, for example to concatenate the shmid to the string 
"SYSV00000000" which is not usable anyway.

On Solaris, you might use this id:
http://www.cs.cf.ac.uk/Dave/C/node27.html

Thanks

Original comment by remi.cha...@gmail.com on 20 Nov 2013 at 8:50