niner
commented
7 years ago If we want to we could just turn lock into a multi and deprecate the current Int-using candidate.
Open zoffixznet opened 7 years ago
niner
commented
7 years ago If we want to we could just turn lock into a multi and deprecate the current Int-using candidate.
Just wanted to take the opportunity to apologize for my laziness when adding IO::Handle.lock. I needed it for the precomp stuff and could have taken the 2 minutes to used named arguments instead of just passing through a confusing Int. Especially since the int in question is platform dependent :/
On most systems 0 will be a read lock (shared) and 1 a write lock (exclusive).
From my own experience I can only say that I have never used a non-blocking file lock. I have always used flock to serialize access to a file (IOW to make it safe). I have never been in a situation where I'd ask "Is someone else working on this file?" and do something else if that's the case. So I strongly suggest making it block by default just as flock() does and just as Lock.lock does.
WRT a default for shared/exclusive I'd go for the latter. Defaulting to exclusive is the safer choice as a naive user would probably just try $handle.lock; $handle.spurt("I'm safe to do whatever I like with this file!"); As concurrency issues are hard enough to test as they are, I'd argue for being on the safe side. The failure mode of an accidentally shared lock is no protection against concurrency issues which may go undetected until in production and even there just silently corrupt data. For an accidentally exclusive lock the failure mode is lower performance (no concurrency) and the possibility for deadlocks - which I dare say will be detected.
The alternative is to not have a default at all and therefore force the user to make a conscious decision. I'd go with exclusive + blocking.