Don't ask to ask, just ask | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
But (based on the assumptions I made in my code snippets: files exist, no interrupts, etc) it should never return until it gets a lock unless you're using LOCK_NB anyway, since it's a blocking call.
Extremely bad assumption. The call can fail for a million and one reasons, some of them rather non-obvious. See your OS for details. For instance do you pay attention to which directories are NFS mounted? Even if you do, does your sysadmin know which directories cannot be NFS mounted without causing nasty (but intermittent) race conditions? No one seems to have found anything wrong with it, so for now I'm assuming it's a valid technique (even if my sample code doesn't implement it completely correctly :) Programming by experiment? That is very risky. Try to find documentation. FYI I have seen cases where you can lose the lock on a file when you close any filehandle on it even if you opened the lock on the other filehandle. Sometimes your code will behave correctly, sometimes not. I don't know details offhand, but if you are relying on the contrary behaviour, be damned sure that you have a test suite so you know that your version of Perl/OS behaves as you expect. You know, locking is the one thing you don't want to get wrong. Because if you do, the signs aren't obvious until a long time later, and they are intermittent. Intermittent problems are the hardest to debug, particularly if you start with a bunch of wrong assumptions about why you are protected. In reply to Re: Re: A flock()alypse now
by Anonymous Monk
|
|