in reply to Re: Don't use unflock (flock 8). Ever.
in thread flock - lordy me....

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

Replies are listed 'Best First'.
Re: Re: Re: Don't use unflock (flock 8). Ever.
by AgentM (Curate) on Jan 16, 2001 at 23:28 UTC
    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