Is it possible to get the Physical memory address of a variable in python?
davea at ieee.org
Tue Nov 10 20:56:17 CET 2009
Ognjen Bezanov wrote:
> Thanks for all the responses guys. In hindsight I probably should have
> explained why on earth I'd need the physical address from an
> interpreted language.
> I'm trying to see if there is any way I can make Python share data
> between two hosts using DMA transfers over a firewire connection, so
> avoiding the need for another layer on top such as IPv4 + Python sockets.
> Thanks to some old python bindings which I updated to python 2.6, I
> can read any write to the RAM of any firewire connected host within
> python. Because it uses DMA (the cpu is not involved in this at all),
> I can only specify a physical address within the 4GB ram limit to read
> from and write to.
> Now what I've done so far is on the remote host I run python and set a
> variable as so:
> a = "foo"
> print a
> Then on the local host I run a python script that scans the entire RAM
> looking for the string "foo", and replaces it with the string "oof". I
> have had success with this method. Once it's done and I do "print a"
> on the remote host, I get "oof" as the variable value, so in theory it
> can work.
> Problem is that it's slow. Scanning 3GB of RAM every time you want to
> do this is not a good method. I thought that if I could get python to
> return the physical address of where the value of a variable is, then
> I can just jump to that address and write the data.
> From what I've been told so far, it's not possible to do this without
> some OS-specific (Linux in this case) syscall. Is this correct?
I'm sure you realize that scanning for a 3 byte tag is not only slow,
but very dangerous. It could easily have been three other bytes which
just happened to match this string. And those bytes could have been
part of a disk directory entry (result disk corruption) or some other
application. Further, between the time you did the search and the time
when you updated, the relevant bytes could have been swapped to disk,
and something else put in the same physical address.
Anyway, I've been assuming all along that you meant address in the sense
that a C program uses it, which is a linear address. But as long as
you're running on an OS that has virtual memory running, there's another
translation going on invisibly to the application, which converts linear
to physical. So even after you get a memory address, you need to
convince the OS to lock such memory in place for awhile, and then tell
you where (physical address) it locked it.
Note also that if a range of addresses spans a 4k boundary (for Intel
architecture), it's possible that the physical addresses are not even
contiguous. But the system calls from Windows (and presumably also from
Linux) can hide that from you, via double-buffering.
More information about the Python-list