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

From: Calvin Morrison <mutantturkey_AT_gmail.com>
Date: Wed, 9 Apr 2014 08:47:14 -0400

> 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.

What is the benefit of using a C program? For me it would be easier to
implement sane flags, but I am lazy. bash makes it easy to prototype
and run with a very small feedback loop and low boilerplate to product
ratio.

> Additionally, pinging the directory every two seconds is simple, but
> not convenient if you have many looks and don't want to wait for
> concurrency-blocks.

I don't see another option. Even using poll, you're still somewhere
checking every x interval if the directory is gone.

> 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
> thread-safe).

i-notify rocks but is linux only afaik.

> 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!

Hmm, how can I do this? I have trouble making it clear without using
two terminals and a video (that would be very easy)

> ###
>
> 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.

So I think that's a moot issue..

Cheers
Calvin
Received on Wed Apr 09 2014 - 14:47:14 CEST

This archive was generated by hypermail 2.3.0 : Wed Apr 09 2014 - 15:00:03 CEST