Re: [dev] lock (1) - a dead simple lock script
> 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