Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
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:
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, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.