Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timeout-free lock acquisition #57

Closed
chrysn opened this issue Dec 12, 2019 · 3 comments
Closed

Timeout-free lock acquisition #57

chrysn opened this issue Dec 12, 2019 · 3 comments

Comments

@chrysn
Copy link

chrysn commented Dec 12, 2019

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.

chrysn added a commit to chrysn/aiocoap that referenced this issue Jan 28, 2020
@gaborbernat
Copy link
Member

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

@axoroll7
Copy link

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

@chrysn
Copy link
Author

chrysn commented Aug 31, 2022

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.

@chrysn chrysn closed this as completed Aug 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants