That could actually be part of this case -- the values are cloned by each process to avoid sync'ing with mutexes at runtime. Each process gets the new value when it executes cfg_update(), which is typically done when a process has something new to do (e.g., process a new sip message). In your test case, as the old value is still referenced by other processes, might not be destroyed.

This part of code is inherited from SER project, I am not very familiar with, that's why I am saying it might be designed for a different purpose than is expected here (i.e., not for use with very often changes of values). My comments here are based on a brief look at the code.

And, as I said, for needs related to values that need to be changed very often via rpc, better use shared variable or shared hash table variables.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.