Re: [dev] lock (1) - a dead simple lock script

From: FRIGN <>
Date: Wed, 9 Apr 2014 13:31:51 +0200

On Wed, 9 Apr 2014 09:54:33 +0200
Martti Kühne <> wrote:

> This [0] turned up on Lennart's G+ page recently, and as I understand
> flock()'ing just over DST change can lead to clusterfuck.
> Since this is being discussed here and the link beneath is mere FUD,
> someone here could be so nice as to clarify.
> Thank you in advance.

Hey Martti,

first off, I'd definitely rewrite this locking-script in C, given it
doesn't use Shell-features excessively.
I see no reason to keep it as a Shell-script.

Additionally, pinging the directory every two seconds is simple, but
not convenient if you have many looks and don't want to wait for
One way is using inotify and IN_DELETE_SELF, which however isn't
POSIX-compliant. Another way could be using poll() or select(), but I'm
not all too familiar with those POSIX-functions (They're not

Now, the usage itself is actually pretty ingenious! I like it!

$lock p # create lock or wait
$lock p && do_work & # create lock or wait
$rmdir p # remove lock
# lock released, do_work

It's much cleaner and easier to grasp than flock or lockrun.

I had trouble understanding this at first, because of the
2-second-intervals and your lacking example in the README.
Make it simpler for the reader!


Now, concerning the main concurrency-issues:
lock actually relies on mkdir's concurrency, which is good[0].
Given it's atomic, it won't allow two concurrent mkdirs at the same
time and location.


The only thing to optimize imho is the way the lockdir is checked.
As you can read in the earlier mails, the motivation behind lock is not
to rely on non-POSIX-calls (like most other locking-tools), but to be
conforming to it.
I pinned those ideas down above. Please let me know, how you would
approach it.



PS: Researching this topic I stumbled upon this post[1].
    A MkDirService? Seriously? Sometimes, I just feel sorry for the


Received on Wed Apr 09 2014 - 13:31:51 CEST

This archive was generated by hypermail 2.3.0 : Wed Apr 09 2014 - 13:36:06 CEST