Skip to content

Conversation

@orivej
Copy link

@orivej orivej commented Sep 12, 2014

This fixes the issue #2.

@derpston
Copy link
Owner

Sorry about the delay getting back to you.

You're right about the race condition. I was puzzled by this because I thought I had fixed it, but it turns out that the code here doesn't match what I published on PyPI. The code on github is out of date, what's on PyPI is correct. I think I must have published there and forgotten to push the repo back here.

Anyway, the point is that I removed the unlink call entirely. I found the race condition, and then found that deleting the file before releasing the lock still has a race condition because another process can create the file after it has been deleted. Since the inodes differ, it can get a new lock on a new file with the same name, so the presence of the lock file doesn't mean much.

I found that simply leaving the lock file in place was preferable. I think some tests are needed, but I doubt I'll get around to that any time soon. What do you think?

@orivej
Copy link
Author

orivej commented Oct 29, 2014

deleting the file before releasing the lock still has a race condition because another process can create the file after it has been deleted

It is a race indeed, but in another situatiton: when a second process opens the file before the lock holder deletes it. Then a third process may create and lock a new file while the second one still holds the lock.

I rather prefer the file to be deleted, so that fine-grained obsolete lock files would not multiply. Here is a safe and simple way to do it: http://stackoverflow.com/a/18745264/1687334

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants