Daftar Isi

• flock FILEHANDLE,OPERATION

  Calls flock(2), or an emulation of it, on FILEHANDLE. Returns truefor success, false on failure. Produces a fatal error if used on amachine that doesn't implement flock(2), fcntl(2) locking, or lockf(3).flock is Perl's portable file-locking interface, although it locksentire files only, not records.

  Two potentially non-obvious but traditional flock semantics arethat it waits indefinitely until the lock is granted, and that its locksare merely advisory. Such discretionary locks are more flexible, butoffer fewer guarantees. This means that programs that do not also useflock may modify files locked with flock. See perlport, your port's specific documentation, and your system-specific local manpagesfor details. It's best to assume traditional behavior if you're writingportable programs. (But if you're not, you should as always feel perfectlyfree to write for your own system's idiosyncrasies (sometimes called"features"). Slavish adherence to portability concerns shouldn't getin the way of your getting your job done.)

  OPERATION is one of LOCK_SH, LOCK_EX, or LOCK_UN, possibly combined withLOCK_NB. These constants are traditionally valued 1, 2, 8 and 4, butyou can use the symbolic names if you import them from the Fcntl module,either individually, or as a group using the :flock tag. LOCK_SHrequests a shared lock, LOCK_EX requests an exclusive lock, and LOCK_UNreleases a previously requested lock. If LOCK_NB is bitwise-or'ed withLOCK_SH or LOCK_EX, then flock returns immediately rather than blockingwaiting for the lock; check the return status to see if you got it.

  To avoid the possibility of miscoordination, Perl now flushes FILEHANDLEbefore locking or unlocking it.

  Note that the emulation built with lockf(3) doesn't provide sharedlocks, and it requires that FILEHANDLE be open with write intent. Theseare the semantics that lockf(3) implements. Most if not all systemsimplement lockf(3) in terms of fcntl(2) locking, though, so thediffering semantics shouldn't bite too many people.

  Note that the fcntl(2) emulation of flock(3) requires that FILEHANDLEbe open with read intent to use LOCK_SH and requires that it be openwith write intent to use LOCK_EX.

  Note also that some versions of flock cannot lock things over thenetwork; you would need to use the more system-specific fcntl forthat. If you like you can force Perl to ignore your system's flock(2)function, and so provide its own fcntl(2)-based emulation, by passingthe switch -Ud_flock to the Configure program when you configureand build a new Perl.

  Here's a mailbox appender for BSD systems.

   use Fcntl qw(:flock SEEK_END); # import LOCK_* and SEEK_END constants
   
   
   sub lock {
   
   my ($fh) = @_;
   
   flock($fh, LOCK_EX) or die "Cannot lock mailbox - $!\n";
   
   
   # and, in case someone appended while we were waiting...
   
   seek($fh, 0, SEEK_END) or die "Cannot seek - $!\n";
   
   }
   
   
   sub unlock {
   
   my ($fh) = @_;
   
   flock($fh, LOCK_UN) or die "Cannot unlock mailbox - $!\n";
   
   }
   
   
   open(my $mbox, ">>", "/usr/spool/mail/$ENV{'USER'}")
   
   or die "Can't open mailbox: $!";
   
   
   lock($mbox);
   
   print $mbox $msg,"\n\n";
   
   unlock($mbox);
   

  On systems that support a real flock(2), locks are inherited across fork()calls, whereas those that must resort to the more capricious fcntl(2)function lose their locks, making it seriously harder to write servers.

  See also DB_File for other flock() examples.

  Portability issues: flock in perlport.