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

From: FRIGN <dev_AT_frign.de>
Date: Wed, 9 Apr 2014 15:10:04 +0200

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

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

Well, every time you run a shell-script you launch a sub-shell, import
all environment variables and, most importantly, depend on the
shell-implementation.
Using C on the other hand, you are able to optimize the program even
more (shell is good for prototyping, but not for long-term-usage if you
have the time to port it to C).
The only reason to use a shell-skript is if you write things that often
need to be changed (like configure-skripts, Makefiles, ...) or if you
depend on shell-functions (which sometimes is pretty neat).

The dead simple lock-software you propose is almost as dead simple to
write in C. I guess you could even stay at the same SLOC or a little
bit more.

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

That depends on the implementation. I wonder why the Kernel-folks
didn't partially implement poll() using inotify.
This way, you would both be able to write POSIX-compliant software and
benefit from the nive inotify-interface.


> i-notify rocks but is linux only afaik.

Yep.

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

Well, don't depend on Terminal quirks too much. Why not just take my
example and annotate it a bit better?

> So I think that's a moot issue..

It's an issue we don't have to worry about, because if mkdir wasn't
thread-safe by implementation, there would be a whole lot of other
problems (just think about the poor fs-implementors).

Cheers

FRIGN

-- 
FRIGN <dev_AT_frign.de>
Received on Wed Apr 09 2014 - 15:10:04 CEST

This archive was generated by hypermail 2.3.0 : Wed Apr 09 2014 - 15:12:07 CEST