3

I'm using boost interprocess for a shared memory application, and I feel like it handles process termination very poorly.

For example, I create a certain data object and store it in memory, with the name map_name. Then, I run this code:

void findContinuously(const char* map_name) {
    managed_shared_memory segment(open_only,"MySharedMemory");
    while(true) {
        DataObject *myMap = segment.find<DataObject>(map_name).first;
        bsl::cout << myMap << bsl::endl;
    }
}

The first time I run it after creating the object, everything is fine. It continuously prints an address. I then ctrl-c it. Run it again. Ctrl-c it. I repeat this process over and over. Eventually, maybe it's run 3, the program hangs, never prints any address, but never exits. I'll ctrl-c it and try again, but to no avail. From here on out, the object is inaccessible. Also, I can no longer create new objects in this managed_shared_memory segment.

I have a theory for why this happens. The managed_shared_memory object guarantees object creation and search are atomic. It probably achieves this by having some mutex in shared memory. The calling process accesses the segment manager, which acquires this mutex. Process dies before segment manager releases the mutex. Mutex is forever locked.

I have this idea because this has happened when I've used my own named shared memory mutex in a different situation. If a program acquires it and dies, the mutex is never unlocked.

Thoughts? I don't have a workaround for this. This is preventing me from using boost interprocess in production, because processes are occasionally killed. I can't risk having the entire block of memory locked. But I find it hard to believe the Boost developers didn't foresee this situation.

CJ Cobb
  • 105
  • 5

1 Answers1

0

Try with typedef for a default basic_managed_shared_memory with null mutex family of narrow characters: typedef basic_managed_shared_memory<char, rbtree_best_fit<null_mutex_family>, iset_index> managed_shared_memory_null_mutex; And use a robust interprocess lock outside the managed_shared_memory_null_mutex, such as system V semphore.

Frank Right
  • 1