in reply to flock - lordy me....

From flock docs:
To avoid the possibility of mis-coordination, Perl flushes FILEHANDLE before (un)locking it.
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.

Replies are listed 'Best First'.
Don't use unflock (flock 8). Ever.
by merlyn (Sage) on Jan 16, 2001 at 22:54 UTC
    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

      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.
        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 }

        -- Randal L. Schwartz, Perl hacker