Fix race at exit. #3
Conversation
|
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? |
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 |
This fixes the issue #2.