Perl provides a built-in function flock() to lock files.
This, by default, uses the flock(2) system call to do the locking,
but can optionally be configured to use the fcntl(2) system call
to do the locking.
flock(2) and fcntl(2) locks are different and incompatible
advisory locks. i.e. if you lock a file with one interface, it will
not appear locked using the other interface. flock(2) has a number
of defects: locks are associated with open file descriptors and are
inherited across forks, and they also don't work on NFS filesystems.
By way of comparison, fcntl(2) works over NFS given a suitably
capable server and client setup, and locks are not inherited over
fork()--they are associated with a process. This behaviour makes
flock(2) unpredictably unreliable if you can't guarantee you will
only be using local filesystems, and makes it hard to implement
servers if your child processes continue to hold locks you hold in
the server.
Apparently, it's possible to configure perl with -Ud_flock (I think
that's the correct option) to make it emulate flock() with fcntl(2).
If there are no compatibility reasons to switching to fcntl for more
robust locking, it might be a nice improvement to use this option.
pp_sys.c shows the necessary configured options to select the
desired behaviour.
Perl itself offers only a high-level interface which is implementable
using either low-level system interface, so well-written Perl programs
should work using either mechanism. The only potential gotcha is that
some programs might be written to rely on the specific subtle
semantics of one implementation. However, having fcntl(2)-compatible
locks rather than old-style flock(2) locks is (IMHO) preferable on
a modern system.
Regards,
Roger