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.

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.

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.

>
> 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?

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.

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

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.

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*

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.