That is great information but some of the things stated there are not true.
Slide 4: Trap #1: LOCK_UN
States that "flock FH, LOCK_UN" doesn't flush the buffer -- not true. This may have been the case in older versions of Perl but not in the current ones. From 'perldoc -f flock'
"To avoid the possibility of miscoordination, Perl now flushes FILEHANDLE before locking or unlocking it."
Slide 7: Trap #2: Failing to check for failure
The thing that threw me here is the example. It states that
flock() may fail if FH is not open. True. But then it also
states that the file will be modified because flock() failed. Not true. How are you going to modify the file if FH is not defined? ;)
The example that should've been there, in my opinion, is the one involving interrupted system calls. If a program is waiting for a lock and it receives a signal, this will result in flock() returning an
error and unless the program checks the return value of flock(), it'll happily proceed with its job even though it doesn't really have a lock.
I don't mean to be picky. Please accept this a constructive critisism. :)
--perlplexer
| [reply] |
States that "flock FH, LOCK_UN" doesn't flush the buffer -- not true.
Well, it *is* true for many folks ;-) And if one is writing a module for public consumption (or for any environment that the potentially don't have complete control of), it is best to be safe. Heating up the pipes of a filehandle that already has buffering turned off can't hurt in this case, it can only ensure safety.
It states that flock() may fail if FH is not open. True. But then it also states that the file will be modified because flock() failed. Not true. How are you going to modify the file if FH is not defined? ;)
The point of Trap #2 is that the flock() system call may fail for some reason. If one doesn't check for a failure of the system call, one could end up modifying a file that they couldn't obtain a lock on, which probably wouldn't be the intended result.
-- dug
| [reply]
[d/l] |