Lock::File - yet another file locking module
I just uploaded a new module: Lock::File.
I guess the main reason I'm writing this blog post is because I feel guilty about it. There are SO MANY other similar modules.
I wanted to review them all, neilb style. I never found time to do it. Damn you, perfectionism.
I don't want to explain my issues with other modules here. I'm not sure if Lock::File is really much better than others, or if I'm just biased because I used it for years. You can look at Lock::File POD and decide for yourself.
But I finally realised that I have too much unreleased code and I've postponed its uploading to CPAN just because I didn't want to duplicate some existing code. Damn you, perfectionism.
In addition to that, the copy of Lock::File, named Ubic::Lockf, was bundled with Ubic for years.
And yet, I feel guilty. Sorry, guys.
I wrote Ubic. I worked at Yandex for many years, and now i'm building my own startup questhub.io (formerly PlayPerl). I'm also working on Flux, streaming data processing framework.
CPAN ID: MMCLERIC.
I'm the author of one of these modules -- File::Flock::Tiny ;). The reason I created my own module is that locking is a bit tricky thing and if I use such a module I want to know exactly what happens inside. So I tried to write something as clear as possible, so it would be easier to see how it works.
I see that you've implemented
removeoption, perhaps you will be interested to read my recent discussion on GitHub with Steven Haryanto about why I'm not going to implement it. On a first glance it looks like situation I described in this comment is applicable to your module.core dump on Windows
I'm the author of yet another locking module: Feel free to have a look at IPC::ConcurrencyLimit and specifically IPC::ConcurrencyLimit::Lock::Flock and/or list them as related modules.
You're right that 'remove' option is tricky. But I believe Lock::File works correctly by comparing stat() of the locked fh with the existing file.
(I'm not sure about the infinite loop in this code, but choosing any limit on retries count feels arbitrary, and exposing implementation details to the user via 'retries' option feels wrong. Maybe I should choose a very big constant, like 1000, just to be safe. Although I can't imagine a situation where inodes are *always* different.)
Ah, I see. Yes, that should solve the problem.
I think it's fairly confusing if not outright wrong that you use the names flock and lockf as if they are synonymous. They have fairly different semantics in POSIX.
Good point.
The origin for lockf() name choice was freebsd lockf utility, which we used long time ago, before Lock::File.
I see how it can be confusing, though, and probably will rename it to something like lockfile().
PS: Filed as https://github.com/berekuk/Lock-File/issues/2.