Messages in this thread | | | From | NeilBrown <> | Date | Thu, 29 Mar 2018 08:34:45 +1100 | Subject | Re: [PATCH 4/6] rhashtable: allow a walk of the hash table without missing objects. |
| |
On Wed, Mar 28 2018, Herbert Xu wrote:
> On Wed, Mar 28, 2018 at 06:17:57PM +1100, NeilBrown wrote: >> >> Sounds like over-kill to me. >> It might be reasonable to have a CONFIG_DEBUG_RHASHTABLE which enables >> extra to code to catch misuse, but I don't see the justification for >> always performing these checks. >> The DEBUG code could just scan the chain (usually quite short) to see if >> the given element is present. Of course it might have already been >> rehashed to the next table, so you would to allow for that possibility - >> probably check tbl->rehash. > > No this is not meant to debug users incorrectly using the cursor. > This is a replacement of your continue interface by automatically > validating the cursor. > > In fact we can make it even more reliable. We can insert the walker > right into the bucket chain, that way the walking will always be > consistent. > > The only problem is that we need be able to differentiate between > a walker, a normal object, and the end of the list. I think it > should be doable.
Yes, I think that could work. The code to stop over a walker object during an unlocked search wouldn't be straight forward and would need careful analysis.
However about storing the hash chains in order by object address? Then rhashtable_walk_start() can easily find it's place regardless of whether the old object was still present or not, using <= on the address. "Insert" would need to record an insert location and insert there rather than at the head of the chain. I might try coding that.
Thanks, NeilBrown [unhandled content-type:application/pgp-signature] | |