Locks created by flock() are associated with a file, or, more precisely, an open file table entry. This means that duplicate file descriptors (created by, for example, fork(2) or dup(2)) refer to the same lock, and this lock may be modified or released using any of these descriptors. Furthermore, the lock is released either by an explicit LOCK_UN operation on any of these duplicate descriptors, or when all such descriptors have been closed.

... so they are shared!

Thanks! So if they share the lock, then would it be safe to say that if the child process closes the file handle then it will no longer have a lock, but the parent will?

yes, the lock being released only "when all such descriptors have been closed" (in the absense of an explicit unlock) means exactly that.

yes!

BTW, I think this behaviour is very OS dependant

The locks are merely advisory, so both the parent and the child (and all other processes) can still read and write from the file. Therefore, the question then boils down to: Who should unlock the file? On FreeBSD, that's apparently up to you to decide:

Locks are on files, not file descriptors. That is, file descriptors duplicated through dup(2) or fork(2) do not result in multiple instances of a lock, but rather multiple references to a single lock. If a process holding a lock on a file forks and the child explicitly unlocks the file, the parent will lose its lock.

Hrrm, that's weird because (quoting from APUE 1st ed, p373):

2. Locks are never inherited by the child across a fork. This means that if a process obtains a lock and then calls fork, the child is considered "another process" with regard to the lock that was obtained by the parent. The child has to call fcntl to obtain its own locks on any descriptors that were inherited across the fork. . . .

And I just looked and OS X has the same verbiage as FreeBSD does (not to surprising, of course :). This may be a BSD-vs-POSIX-vs-SysV thing; at any rate check your OS's flock(2) docs. (Heh. "flock doc" . . .)

--
We're looking for people in ATL

well, this way, the programmer can decide where he wants to use the lock, on the parent or on the child, and just close the file on the other process (or not use it at all).

AIUI, the parent and child processes are one and the same up the point of forking, so whatever "ownership" of the lock there is (if one can call it that) is held by both processes. But I think this is not the best way to think about it. The important thing is that the a file is marked by the OS as being locked (it doesn't matter by whom) so that other processes (those who are playing nice anyway) that attempt to get a lock while the first lock is in effect will use the failure inability to obtain the lock as an indication that they should wait because the file is "busy".

by default, flock doesn't fail when another process already has a lock on the file, it just waits until all the incompatible locks are gone.

To make flock non blocking you have to use the LOCK_NB flag.

amusingly enough, both Perls on Cygwin and WinXP hang on the following:

#! perl -lw
use strict;
use Fcntl ':flock';
open my $fh, "<", "whatever" or die $!;

flock $fh, LOCK_EX;
flock $fh, LOCK_EX;
[download]

this:

open my $fh, "<", "whatever" or die $!;
flock $fh, LOCK_EX;

my $pid = open my $pip, "|-";
die "open(): $!" unless defined $pid;
if ($pid > 0) { close $pip }
else          { flock($fh,LOCK_EX); print "got the lock"}
[download]

if ($pid > 0) { flock($fh,LOCK_EX); print "got the lock" }
else          { sleep(20) }
[download]

Moral: flocks are weird. I will not fork a flock (or flock a fork), unless in dire need of weird behaviour..
update: fixed open fail check, thanks to spotter tlm

In particular, if only the child is going to be using the locked file handle, why would you need or want to open/lock the file before forking? You could just do this in the child process after the fork, and not worry about what happens across a fork. The same reasoning would apply if only the parent were doing stuff with the file in question. OTOH, if the plan is for the parent to do something with the locked file either before or after the child works on it, why even do the fork in the first place (unless there is enough other stuff to do, not involving the file, that makes the fork worthwhile)?

Now, if your idea is that both child and parent are going to be doing things "in parallel" with this one locked file, you're likely to run into problems whose symptoms might be really strange, unpredictable and hard to debug. One of the main reasons for file locking in the first place is to keep concurrent processes from trampling each other when working with the same external resource.