Cross platform mutex to prevent script running more than instance?
Cameron Simpson
cs at cskk.id.au
Tue Sep 4 18:47:27 EDT 2018
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>
More information about the Python-list
mailing list