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

From: Calvin Morrison <mutantturkey_AT_gmail.com>
Date: Wed, 9 Apr 2014 09:12:52 -0400

On 9 April 2014 09:10, FRIGN <dev_AT_frign.de> wrote:
> 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.

Fair enough I think I will implement it in C at some point then.

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

Doesn't i-notify work via some polling in itself as well?

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

Okay will do
Received on Wed Apr 09 2014 - 15:12:52 CEST

This archive was generated by hypermail 2.3.0 : Wed Apr 09 2014 - 15:24:06 CEST