cross-process ref-counts to 0; at which point shm::Pool_arena logic will deallocate those objects. Deallocation is entirely distributed between A and B; in this scenario B's handles just happen to live longer and therefore happen to be the ones triggering the deallocations &ndash; by the B process itself, synchronously. A is not "in charge" of deallocations of anything in any special way; it doesn't matter which process originally allocated a given object either. That's the beauty/simplicity of SHM-classic.