Cross platform mutex to prevent script running more than instance?

[Cameron Simpson]

On 04Sep2018 07:57, CFK <cfkaran2 at gmail.com> wrote:
>What about using flock()? I don't know if it works on Windows, but it works
>really well for Unix/Linux systems.  I typically create a log file in a
>known location using any atomic method that doesn't replace/overwrite a
>file, and flock() it for the duration of the script.

Please adopt the inline reply format. Thanks.

The good things about flock() and open(O_EXCL) and other variations is that if 
your program aborts (or its OS aborts) the lock goes away. The downside is that 
it is less cross platform (including network filesystems). Even ignoring 
nonUNIX systems I have counter examples: I've got a (pretty dumb) embedded 
Linux box here whose NFS doesn't support locking. SO flock() goes out the 
window if the lock uses it.

Now, many use cases are single machine or may never meaningfully use a network 
filesystem. But if I'm writing _library_ code then I, as the author, don't know 
who will be calling my code in the future. So my inclination is to go for mkdir 
because it is so portable and robust.

The downside with mkdir, and also with pd files really, is that a program or OS 
abort can leave them lying around. Being persistent objects, some kind of 
cleanup is needed. For me, that is usually a price I'll accept in order to have 
a robust works-anywhere tool.

Aside: pid files? How do you know they're really stale? PIDs can be reused. On 
Linux and many UNIXes, PIDs get reused really fast (sequentially allocated); 
even OpenBSD with its cool unpredictable PIDs has this issue to a lesser 
degree.

What you can get away with depends on your use cases. If you like automatic 
cleanup, flock and its file descriptor based variants are simple and at least 
always go away on program exit, whatever the reason. If you can wear some 
cleanup, mkdir is portable and releiable. (And you can store state information 
inside the dir!)

Given the subject line ("Cross platform mutex to prevent script running more 
than instance") I'd go for mkdir myself.

Cheers,
Cameron Simpson <cs at cskk.id.au>

>Thanks,
>Cem Karan
>
>On Mon, Sep 3, 2018, 11:39 PM Cameron Simpson <cs at cskk.id.au> wrote:
>
>> On 03Sep2018 07:45, Malcolm Greene <python at bdurham.com> wrote:
>> >Use case: Want to prevent 2+ instances of a script from running ...
>> >ideally in a cross platform manner. I've been researching this topic and
>> >am surprised how complicated this capability appears to be and how the
>> >diverse the solution set is. I've seen solutions ranging from using
>> >directories, named temporary files,  named sockets/pipes, etc. Is there
>> >any consensus on best practice here?
>>
>> I like os.mkdir of a known directory name. This tends to be atomic and
>> forbidden when the name already exists, on all UNIX platforms, over remote
>> filesystems. And, I expect, likewise on Windows.
>>
>> All the other modes like opening files O_EXCL etc tend to be platform
>> specific
>> and not reliable over network filesystems.
>>
>> And pid based approaches don't work cross machine, if that is an issue.
>>
>> Cheers,
>> Cameron Simpson <cs at cskk.id.au>