Re: A flock()alypse now

You're right: I didn't do any error checking on the flock() calls. I should have. 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.

But that's not really the primary point of my post. I was wondering if anyone knew of any problems with opening the_file multiple times, once for locking and once for reading/writing/etc. Update: ~~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 :)~~ Please tell me if you can see anything wrong with the basic technique I presented in my original node, independant of the actual code used to implement it.

Thanks,

Alan

Update, re AN's comments: It's sample code. It was meant to demonstrate a point, not to be complete, or even to work (since I didn't know if it did). I think my point and question were demonstrated more clearly and concisely by making these assumptions instead of by increasing the sample code beyond the size of easy readability.

Thank you for your clarifications and comments on my methods. Clearly, knowing the environment you're working in plays an important part in determining what assumptions are safe to make and which aren't, in your specific case. But without some assumptions, you can't even count on things as basic as the behavior of the particular OS you assume you're running under.

Comment on Re: A flock()alypse now Select or Download Code

Replies are listed 'Best First'.
Re: Re: A flock()alypse now by Anonymous Monk on Jul 03, 2002 at 11:49 UTC
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.	[reply]

Replies are listed 'Best First'.

Re: Re: A flock()alypse now
by Anonymous Monk on Jul 03, 2002 at 11:49 UTC

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.

[reply]