www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Is there an object on given memory address?

reply "tcak" <tcak gmail.com> writes:
Is there any "reliable" way to determine whether there is a 
certain type of object in memory at a given address?

I am going to send the memory address of an object to another 
program over pipes. Then after a while, other program will send 
that memory address, and main program will try to address the 
object. (Please do not concern about security). What I am worried 
about is whether the object is still there, or garbage collector 
has already removed it, or another object has come on same 
address.
Feb 12 2015
parent reply "tcak" <tcak gmail.com> writes:
On Thursday, 12 February 2015 at 10:03:18 UTC, tcak wrote:
 Is there any "reliable" way to determine whether there is a 
 certain type of object in memory at a given address?

 I am going to send the memory address of an object to another 
 program over pipes. Then after a while, other program will send 
 that memory address, and main program will try to address the 
 object. (Please do not concern about security). What I am 
 worried about is whether the object is still there, or garbage 
 collector has already removed it, or another object has come on 
 same address.
BTW, I have already got the address of object into a "size_t" type variable and sent it. That is not the problem part.
Feb 12 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 12 February 2015 at 10:04:29 UTC, tcak wrote:
 BTW, I have already got the address of object into a "size_t" 
 type variable and sent it. That is not the problem part.
How reliable do you want? You would have to either "pin the object" by registering a root to it to prevent it from being moved or freed. http://dlang.org/phobos/core_memory.html#.GC.addRoot Or send a hash of the object along with the memory address, then query the GC wether the memory is still allocated.
Feb 12 2015
next sibling parent reply "tcak" <tcak gmail.com> writes:
 Or send a hash of the object along with the memory address, 
 then query the GC wether the memory is still allocated.
This part sounds interesnting. How does that GC querying thing works exactly?
Feb 12 2015
parent "Baz" <bb.temp gmx.com> writes:
On Thursday, 12 February 2015 at 11:14:05 UTC, tcak wrote:
 Or send a hash of the object along with the memory address, 
 then query the GC wether the memory is still allocated.
This part sounds interesnting. How does that GC querying thing works exactly?
std [doc][1] is your friend but if you need guidance. --- import core.memory : GC; bool is_gc_allocated = addrOf(ptd) != null; --- [1]: http://dlang.org/phobos/core_memory.html#.GC.addrOf
Feb 12 2015
prev sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 12 February 2015 at 10:16:49 UTC, Ola Fosheim 
Grøstad wrote:
 then query the GC wether the memory is still allocated.
This is racy, though. Someone (or the GC) could have freed the object in the meantime, and a new object of potentially different type could have taken its place. You won't get around pinning it.
Feb 12 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 12 February 2015 at 15:53:07 UTC, Marc Schütz wrote:
 On Thursday, 12 February 2015 at 10:16:49 UTC, Ola Fosheim 
 Grøstad wrote:
 then query the GC wether the memory is still allocated.
This is racy, though. Someone (or the GC) could have freed the object in the meantime, and a new object of potentially different type could have taken its place. You won't get around pinning it.
It will statistically work for objects that are large and have high entropy. Just hash the fields you want to be the same. If entropy is a problem add a unique instance id that is a large random bit string and make sure it is cleared when the object is released. It's the same technique used for IDs in distributed systems under the assumption that the probability of hardware failure is larger than the probability of a ID collision... but you have to do the math to be sure that the probability of failure is acceptable.
Feb 12 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 12 February 2015 at 16:27:21 UTC, Ola Fosheim 
Grøstad wrote:
 On Thursday, 12 February 2015 at 15:53:07 UTC, Marc Schütz 
 wrote:
 On Thursday, 12 February 2015 at 10:16:49 UTC, Ola Fosheim 
 Grøstad wrote:
 then query the GC wether the memory is still allocated.
This is racy, though. Someone (or the GC) could have freed the object in the meantime, and a new object of potentially different type could have taken its place. You won't get around pinning it.
It will statistically work for objects that are large and have high entropy. Just hash the fields you want to be the same. If entropy is a problem add a unique instance id that is a large random bit string and make sure it is cleared when the object is released. It's the same technique used for IDs in distributed systems under the assumption that the probability of hardware failure is larger than the probability of a ID collision... but you have to do the math to be sure that the probability of failure is acceptable.
Whoaa, that's just horrible! *shudder*
Feb 12 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 12 February 2015 at 16:56:24 UTC, Marc Schütz wrote:
 Whoaa, that's just horrible! *shudder*
I know, but it works.
Feb 12 2015