[sr-dev] [kamailio/kamailio] mqueue: add mqueue_mode modparam (PR #3053)

[Daniel-Constantin Mierla]

It is expected to be slower for larger number of items in the queue. There can be some improvements by keeping a hash table with the names of the items in the key to speed up the search, but that will also add to complexity.

>From my point of view, this would be a specific use case where one has to be aware of consequences to processing speed. But if it useful in some cases, then that's how it is.

In other words, I am still fine to merge it, but I think there has to be no unlock (lock release) after the if with the mode:

  * https://github.com/kamailio/kamailio/pull/3053/commits/8a3587004c27f1dc2aaa078c6508f5606124ccba#diff-32730fc08fc59be73bbefa3ec2551f08013719505f9f057d865e4c688a896a79R342

And the next lock_get() has to be removed. Practically, everything has to be done in a single lock_get() ... lock_release(), otherwise there is a short time frame open for races: the if block does not find the item with the name, does lock release, loses CPU for a while, and during that time another process adds an item with the same name.

The penalty is that the shm alloc and copy for the new item is done inside the lock. But probably a condition on `mh->addmode` can be leveraged to do the lock/unlock at the better place, because `mh->addmode` is set at startup and never changes, plus that `mh` does not get destroyed during runtime.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3053#issuecomment-1077625284
You are receiving this because you are subscribed to this thread.

Message ID: <kamailio/kamailio/pull/3053/c1077625284 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20220324/76ff8e06/attachment-0001.htm>