Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<pre><code>int my_shmid = shmget(key,size,shmflgs); ... void* address_of_my_shm1 = shat(my_shmid,0,shmflags); Object* optr = static_cast&lt;Object*&gt;(address_of_my_shm1); </code></pre> <p>...or, in some other thread/process to which you arranged to pass the <code>address_of_my_shm1</code> ...by some other means</p> <pre><code>void* address_of_my_shm2 = shat(my_shmid,address_of_my_shm1,shmflags); </code></pre> <p>You may want to assert that <code>address_of_shm1 == address_of_shm2</code>. But note that I say "may" - you don't actually have to do this. Some types/structs/classes can be read equally well at different addresses.</p> <p>If the object will appear in different address spaces, then pointers outside the shhm in process A may not point to the same thing as in process B. In general, pointers outside the shm are bad. (Virtual functions are pointers outside the object, and outside the shm. Bad, unless you have other reason to trust them.)</p> <p>Pointers inside the shm are usable, if they appear at the same address.</p> <p>Relative pointers can be quite usable, but, again, so long as they point only inside the shm. Relative pointers may be relative to the base of an object, i.e. they may be offsets. Or they may be relative to the pointer itself. You can define some nice classes/templates that do these calculations, with casting going on under the hood.</p> <p>Sharing of objects through shmem is simplest if the data is just POD (Plain Old Data). Nothing fancy.</p> <p>Because you are in different processes that are not sharing the whole address space, you may not be guaranteed that things like virtual functions will appear at the same address in all processes using the shm shared memory segment. So probably best to avoid virtual functions. (If you try hard and/or know linkage, you may in some circumstances be able to share virtual functions. But that is one of the first things I would disable if I had to debug.)</p> <p>You should only do this if you are aware of your implementation's object memory model. And if advanced (for C++) optimizations like splitting structs into discontiguous hot and cold parts are disabled. Since such optimizations rae arguably not legal for C++, you are probably safe.</p> <p>Obviously you are better off if you are casting to the same object type/class on all sides. You can get away with non-virtual functions. However, note that it can be quite easy to have the same class, but different versions of the class - e.g. differing in size, e.g. adding a new field and changing the offsets of all of the other fields - so you need to be quite careful to ensure all sides are using the same definitions and declarations.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload