I'm implementing a Linux application that supports live software upgrade (without process restart). To support this functionality I have broken my application into two parts

1. Module proxy - Frontend of my application that interacts with outside processes
2. Module implementation - Dynamic shared module that can be unloaded and reloaded with the new implementation during program update.

High level approach is to bring the application to a quiescent state, hold incoming messages in a message queue and the replace the old shared module (using dlopen) with the new implementation in the module proxy.

However, during upgrade phase I will have two instance of similar shared object, old module implementation and new module implementation dynamically loaded into module proxy at the same time. Is this possible? Will it cause symbol collision? What's the best way to achieve this state safely?

CodePudding user response：

On Glibc systems (i.e. Linux) you can load copy of shared object to dedicated namespace via dlmopen API. After that you can get access to it's functions via dlsym.

CodePudding user response：

Dynamic shared module that can be unloaded and reloaded with the new implementation during program update.

In general this approach is fraught with peril. In particular, calling dlclose may not actually unload the library when you expect. The rules for when a library can and can not be unloaded are subtle and not well documented.

You should try to dlopen(), use the library, then dlclose() it, and verify that it is actually unloaded (by examining /proc/$pid/maps).

The "two processes" approach suggested by KamilCuk is going to be significantly more reliable.

I considered two process approach but moving messages between two processes might cause performance issue

1. An application which works 100% but is a bit slower usually beats an application which is 10% faster but works only 99% of the time.
2. You should measure performance before deciding to use potentially unreliable architecture.
3. There are ways to use IPC almost as fast as single-process (e.g. shared memory).

yugr@ suggests using dlmopen(), which might work. But it is even less documented and tested, and is also Linux-specific.

during upgrade phase I will have two instance of similar shared object

That is going to be even more problematic, but it's unclear why you can't dlclose() the old version before dlopen()ing the new one.