Re: Fork + Flock = Who Gets the Lock?

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.

Comment on Re: Fork + Flock = Who Gets the Lock?

Replies are listed 'Best First'.
Re^2: Fork + Flock = Who Gets the Lock? by Fletch (Bishop) on Jun 03, 2005 at 20:09 UTC
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	[reply]
Re^3: Fork + Flock = Who Gets the Lock? by salva (Canon) on Jun 03, 2005 at 20:19 UTC
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).	[reply]