digitalmars.D.learn - Is there an object on given memory address?
- tcak (9/9) Feb 12 2015 Is there any "reliable" way to determine whether there is a
- tcak (3/12) Feb 12 2015 BTW, I have already got the address of object into a "size_t"
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (7/9) Feb 12 2015 How reliable do you want? You would have to either "pin the
- tcak (2/4) Feb 12 2015 This part sounds interesnting. How does that GC querying thing
- Baz (7/12) Feb 12 2015 std [doc][1] is your friend but if you need guidance.
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (5/6) Feb 12 2015 This is racy, though. Someone (or the GC) could have freed the
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (10/17) Feb 12 2015 It will statistically work for objects that are large and have
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (3/23) Feb 12 2015 Whoaa, that's just horrible! *shudder*
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (2/3) Feb 12 2015 I know, but it works.
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
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
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. 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
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
On Thursday, 12 February 2015 at 11:14:05 UTC, tcak wrote:std [doc][1] is your friend but if you need guidance. --- import core.memory : GC; bool is_gc_allocated = addrOf(ptd) != null; ---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
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
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: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.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
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:Whoaa, that's just horrible! *shudder*On Thursday, 12 February 2015 at 10:16:49 UTC, Ola Fosheim Grøstad wrote: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.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
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