in reply to Re: flock - lordy me....
in thread flock - lordy me....

Yes, and while that handles the common (mistaken) case of
  1. open for append
  2. flock 2
  3. append
  4. unflock
  5. close
that does nothing for
  1. open for read/write
  2. flock 2
  3. read/write
  4. unflock
  5. repeat back to step 2 as needed

Because there's nothing in that sequence that refreshes the buffer between flock 2 and read, and yet someone else could have messed with the file to get your buffer and the file out of sync. So still, unflock is almost always a danger sign, even with the workaround.

In summary: unflock (flock 8) is not needed when you're about to close, and has to be handled very carefully if you're leaving the file open. Don't use unflock until you know why I say don't use unflock. {grin}

-- Randal L. Schwartz, Perl hacker

Replies are listed 'Best First'.
Re: Don't use unflock (flock 8). Ever.
by AgentM (Curate) on Jan 16, 2001 at 23:04 UTC
    So, to sum it up, there is no 100% dependable synchronization method for a Perl program that needs to synchronize outside of the interpreter? Is this right?
    AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
[reply]
      No, you just have to do it right. 
      open F, "+<somefile" or die;
while (1) {
  flock F, 2;
  seek(F, 1, 0); # this is the part people forget, resyncs the buffer
  hack(\*F); # work with F in any way you want
  flock F, 8; # flush and unlock
}

      [download]

      -- Randal L. Schwartz, Perl hacker

[reply]
[d/l]
        On that note, could a perl module be made to act as a dependable mutex, conditional wait variable, or semaphore using your flock method on some temp file? That would be very nice. I can't help but to wonder if your code is portable. It seems more like a trick than a solution. The original intention of flock was advisory locking which MacOS<X doesn't support (mandatory locking only which is not much better), so I wonder if this method would be of any use other than competing CGIs. Obviously, if some other program competing for the file doesn't use this exact flock, there is no synchronization solution. I can't help but wonder if the Mac's flock is implemented within MacPerl itself (since on MacOS<X, only one instance of a program may run at any given time). I think that this could be easily translated into some Mac::MoreFiles code, though.
        Also, in what situation would one use your above polling loop? If you're analyzing a constantly changing file, then you would most likely rather use record locking via fcntl which, of course, brings up yet more synchronization issues. THREAD ALERT: Woah! If I were to implement muteces, etc. via your method, then I would have an excuse to recommend use Threads;. (Though conditional waits may be prohibitively expensive...or would semaphores...hmmm....*type*type*type*)
        AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
[reply]
[d/l]

In Section Meditations