> 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
