Ok, lets take an example or two:
1) A process locks a file with flock(), forks a child and then exits.
According to flock() semantics the child should share the lock with its
parent and become the sole owner of that lock once the parent has exited.
According to fcntl() semantics the file is unlocked when the parent exits,
the child's never inherits its parent's locks.
2) A process locks a file with flock(), forks a child and waits.
According to flock() semantics, the child can place a write lock on
the file, or unlock the file, since it shares the locks with its parent.
According to fcntl() semantics the child cannot place a write lock on
the file, or unlock it. It shares nothing with its parent.
3) A process locks a file with flock(), dup()'s the file descriptor
and closes the original descriptor (typical when setting up a pipe).
According to flock() semantics, the last close on a file removes the
lock.
According to fcntl() semantics, closing a file descriptor removes all
the locks for that descriptor.
So:
The broken flock() emulation does nothing more than map flock() calls
to "equivalent" fcntl() calls, where equivalent means that LOCK_SH ==
F_RDLCK, LOCK_EX == F_WRLCK, LOCK_NB calls F_SETLK, without LOCK_NB
F_SETLK is called. If your code relies on any of the 3 points outlined
above then it may get *very* surprising results from the emulation.
Referring once again to that old cherry "sendmail" - sendmail does lots
of file locking and forking - compiling it to use the broken flock()
emulation caused no end of trouble. That's why the sendmail default
on Linux is to use fcntl(), not flock() - but that leads to even more
problems......
-Andy
-- Andy Walker Kvaerner Engineering a.s. Andrew.Walker@lysaker.kvaerner.no P.O. Box 222, N-1324 Lysaker, Norway......if the answer isn't violence, neither is your silence......