Thanks, informative slides.
Regarding slide #4 (Trap #1: LOCK_UN) surely it is no longer the case, since per "perldoc -f flock": "To avoid the possibility of miscoordination, Perl now flushes FILEHANDLE before locking or unlocking it."?
Also, thanks for the suggestion but I really do not want syslog for this.
| [reply] |
sedusedan,
I didn't previously think about the consequences of slide #4, but it probably is why I don't 'flock' the actual file. I use a dummy file called ".../LOCK", that I use 'flock' to lock/unlock. This file is alway of length '0', so that allows the actual file that I'm writing/reading to continue to be buffered. You have to use it the exact same way. ('LOCK_EX' for write, 'LOCK_SH' for read.)
As long as you're preventing the race condition by always 'flock'ing the dummy file, you will not get into trouble. Early on I found problems with 'flock'ing the actual file, which may be why 'flock' was fixed to eliminate the problem described in slide #4. But buffering is good!
I looked at your benchmark, and noticed that you don't delete the file each time your script is entered and before you start the benchmark. Even though you're 'open'ing the file with append, you may distort the results due to more disk head activity by having a larger and larger file with each additional call. I adjusted your script and did a comparison to 'syslog' and found that 'syslog' was about twice as slow. I'm guessing that is the socket activity between different processes. Anyway, looks like you have a plan.
Good Luck...Ed
"Well done is better than well said." - Benjamin Franklin
| [reply] |
Hi Ed,
In the actual module (File::Write::Rotate, now already uploaded to CPAN), I do use a zero-length dummy file (lock file).
Regarding not deleting the data file for every script: you have good eyes :) Actually I did truncate the file before each test, but I didn't include it in the post. So, my bad.
Also, thanks for comparing with syslog. Nice to know.
| [reply] |