Cool. I've often used flock to ensure only one instance of a program is running, but I never thought of opening $0 and locking that - consequently each of my scripts litters the filesystem with a matching .lck file.
| [reply] |
| [reply] |
On slide 5 you state:
LOCK_UN should be considered for experts only
Could you provide an example of how it would be beneficial for an 'expert' to use it? Would it not be more appropriate to say "LOCK_UN shouldn't be used. Period.?"
| [reply] |
Could you provide an example of how it would be beneficial for an 'expert' to use it? Would it not be more appropriate to say "LOCK_UN shouldn't be used. Period.?"
If several scripts are appending to the end of a file multiple times, they might make use of LOCK_UN to take turns locking the file, seeking to the end, writing to, then unlocking the file. Though in most cases its better just to close, reopen, and lock the file again (e.g., for the purpose of writing log files, especially when log files are cycled).
Another use might be to lock $0 so that no other process can run some part of a script at the same time, but then at some point in the script it might be deemed safe (and beneficial) to allow other processes to run the script and so use LOCK_UN. Again, its a matter of choice whether to use LOCK_UN or just close, reopen, and lock the file. Maybe someone else has better examples...
| [reply] |
You missed a ton of issues that cause lots of fun. For instance you sometimes cannot lock a file for unexpected reasons. People often don't check $!, and will take a while to track down that. (People who don't check failure are simply hosed.)
Another biggie is that people close a file while they have locks on it open. This may happen for them unexpectedly (eg they have locked a dbm which closes and opens the file behind their back) or because they don't realize that this loses the lock. (Opening the file on a second filehandle and closing that loses the lock on the first still-open filehandle. So that attempted workaround fails!)
Otherwise useful if basic. | [reply] |
Of course it's basic. Did you expect a 10 minute talk to go into incredible detail about file locking? It's just not possible.
Unfortunately, I prepared 15 minutes' worth of material for a 10 minute talk.
So that's more than Dominus should have offered.
John J Reiser
newrisedesigns.com
| [reply] |
open SELF, "< $0" or die ...;
Should be:
open SELF, "+< $0" or die ...;
Due to the fact that some OS's won't allow an exclusive lock on a file that has been opened for read only.
-Nitrox | [reply]
[d/l]
[select] |
