libelektra: ksAppendKey locks name, ksPop does not unlock name
It makes sense that ksAppendKey() locks the key name, since it determines the position of the key in the keyset. However, I did not find an API function that clears the KEY_FLAG_RO_NAME flag.
It would seem intuitive to me, that ksPop (or lookup with KDB_O_POP) would unlock the name again. Is a key not meant to be re-used? Am I missing some important part of the API design, or would my suggestion be of interest.
The question comes from the context of writing the storage plugin tests/scenarios. I moved many tests out of my mmapstorage plugin to ctest. Currently, it tests dump and mmapstorage only.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 24 (19 by maintainers)
Commits related to this issue
- doc: add todo see #2202 — committed to ElektraInitiative/libelektra by deleted user 6 years ago
- decision: add reference to issue #2202 — committed to atmaxinger/libelektra by atmaxinger 2 years ago
- decision: add reference to issue #2202 — committed to joni1993/libelektra by atmaxinger 2 years ago
- decision: add reference to issue #2202 — committed to Dynamichost96/libelektra by atmaxinger 2 years ago
Yes, of course the simplest solution is to not lock/unlock. But then it is kinda hard to keep track whether a
Keyis contained in aKeySet, i.e. whether it is safe to change its name.Yes, that’s basically what I had in mind. The way I would phrase it is that the lock for the keyname is not a simple binary lock (locked/unlocked), but is more like a semaphore. If you lock the keyname
Ntimes, you also need to unlock itNtimes before it is writeable again. I wouldn’t actually call it a second “reference counter”, because then you need to distinguish different kinds of references and that just complicates everything.I don’t see how this “counted lock” could be incorrect.
Yes, maybe it is a non-issue, especially if we remove/rename
ksPop. We could probably just improve the documentation and state that a key name can not be changed even after aksPop. That was my main issue, I was under the impression that i could reuse a key afterksPop.I think we can do this as part of the breaking changes series.
I’ve encountered the same issue in the pluginprocess library and worked around by copying the relevant stuff manually after i finally understood what caused the issue 😃 To me this behavior was also unintuitive.