Lock plugin

[KurtMi]

No description provided.

[markus2330]

Are you sure you want to use that e-mail address? I think they shut it down when you leave TU.

[KurtMi]

I don not have a proper email, can I have a @libelektra.org mail?

[markus2330]

I have sent you an e-mail to your new address!

[KurtMi]

Thank you

[markus2330]

Thank you!

[markus2330]

Btw. nice plugin, is this really your first one? Where there any difficulties?

[markus2330]

Btw. I think we found a use case for this kind of plugin: When we do not have or should not (NFS) rely on timestamps this could be useful.

Your strategy would already work if only the kdb tool is used, but it would not handle long-living processes that do multiple kdbSet?

So following tasks would be required to make a plugin for NFS-conflict detections out of it:

• rename it to something less generic, unless you plan to have multiple locking features combined in this plugin (including the global lock proposed)
• hold lock from first kdbGet() until kdbClose() (for multiple kdbSet())
• release lock when pid behind the lock is already gone
• avoid the busy loop

@tom-wa do you have some further suggestions regarding NFS?

[KurtMi]

I update the plugin in this PR to the ordered global plugin, the simple-lock plugin as you proposed will follow soon.

[KurtMi]

Btw. yes the first plugin, got the knowledge from reviewing and the copy-template works fine.

[markus2330]

It makes sense to favor the writers (because readers should get up-to-date information), but I cannot follow your explanation. Do you mean expensive instead of expansive? What has the run-time cost to do with preference?

merging is not a part of kdbSet, but validation is.

[markus2330]

Looks really nice! Can you rename it to semlock? Btw. the simple-lock: plugin names should be a-z0-9 only, so maybe longlock?

Did you try to run it with the race test?

[KurtMi]

Did you try to run it with the race test?

I tried but failed, it seems that the global hooks are being called a little weird.

I inserted printfs in the kdb.c, when the hooks get called and configured the global plugins that semlock is the only plugin and I get this output:

> kdb set /test/asd "asd"
OPEN
OPEN
OPEN
OPEN
PREGETSTORAGE
24966 PRE GET START
24966 PRE GET END
POSTGETSTORAGE
24966 POST GET START
24966 POST GET END
PREGETSTORAGE
24966 PRE GET START
24966 PRE GET END
PREGETSTORAGE         <---why is here a PREGETSTORAGE? 
24966 POST GET START
24966 POST GET END
CLOSE
CLOSE
PREGETSTORAGE
24966 PRE GET START
24966 PRE GET END
POSTGETSTORAGE
24966 POST GET START
24966 POST GET END
Using name system/test/asd
Set string to asd
24966 PRE SET START
24966 PRE SET END
POSTCOMMIT
24966 POST SET START
24966 POST SET END
CLOSE
CLOSE

Note that the PRESETSTORAGE is not printed.

Also I am worried about:

// resolver says that sync is
// not needed, so we
// skip other pre-commit
// plugins

in kdb.c:770. Without releasing set call no other process can make a get.

[markus2330]

The placement of hooks is an ongoing discussion, see #555. I even thought about giving special placement especially for lock plugins (lockgetstorage, ..., unlocksetstorage). This would ensure that locks are always executed before and after any other plugins (without needing to resort of some weird ordering constructs).

Thus these global locking plugins are not really useful as "normal" plugins, we would not really lose something that way. And this way we could place the global plugins specifically in mind that it will always unlock if it was locked before. (and avoid such problems as in kdb.c:770)

@KurtMi @tom-wa what do you think?

[KurtMi]

We should discuss that topic after the meeting tomorrow. I will create an issue for the longlock, as reminder for me.

[KurtMi]

I adjusted the tags and rating. I think it can be merged.

[markus2330]

Thank you! Let us discuss it tomorrow.