The way it works now is to change values in the database (or text file) and issue reload at once for all the records. The reload doesn't affect ongoing traffic, the module loads first all records in a new structure and then it swaps with the old one very quick. This is the reason that other modules do similar thing, such as mtree.

The structures with the destinations of dispatcher module are optimised for reading in the memory. What you want would require to put those structures behind locks (mutexes) or add some more complex reference counting system in order to block when writing. This could impact the performances significantly, because read operations would also require to acquire the lock or the updates can happen rather late as reference counter can be high with high traffic and the write has to block new readers until old readers finish and it can update in memory. Not sure if the above is clear, but in other words, I do not think this is something we should add, it adds complexity, also at the expense of performance.

I am closing it, personally I am not going to work on such features. However, if you or someone else wants to discuss more, feel free to reopen. Also, if someone wants to go and implement, we can review the patch and based on performance results and the complexity, we can decide what we can do with it.

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