filelock Timeout-free lock acquisition

For an application that has no hopes of waiting for a lock to become usable (in my case, avoiding the simultaneous execution of two server processes on the same state file), I'd need locks that fail immediately when held by another process.

The trivial timeout value I'd like to pass, 0, has a different meaning, though: "poll indefinitely"; the None value that would lend itself to the desired behavior is also used differently (meaning "use the default for that lock").

My current workaround is to just pass 0.001, and it works. (Given the user story there is "start the server, see that it fails immediately", that's immediate enough).

It would be nice to have a documented way of getting immediate-return behavior. For API stability reasons, neither redefining 0 or None are viable. One way to introduce the desired behavior is to have a filelock.RETURN_IMMEDIATELY value (an object(), a string or even 0.000000001) that can be passed in as a timeout argument to indicate that return or error should show immediately.

Dec 12 '19 10:12 chrysn

Hello, if you make a PR for this (with tests) we would be happy to review, thanks!

Sep 27 '21 08:09 gaborbernat

Is your issue resolved now ? If it is the case, can you close the issue please.

Aug 21 '22 09:08 axoroll7

I tried to reproduce the issue with the latest release, and it appears to be well-behaved w/rt a timeout=0. Then again, so does the release that was current at the time I've opened the issue. For lack of a way to reproduce it, and as it is apparently not relevant any more, I'm closing it.

Thanks for your input, and for providing this library.

Aug 31 '22 11:08 chrysn