On Fri, 17 Nov 2006 19:54:13 +0100, Kurt Roeckx <[EMAIL PROTECTED]> wrote:
>I actually see no good reason to want to use flock() over fcntl(). Maybe because the fcntl() >interface follows the completely stupid semantics of System V and >IEEE Std 1003.1-1988 (``POSIX.1'') that require that all locks associated >with a file for a given process are removed when any file descriptor for >that file is closed by that process. This semantic means that applica- >tions must be aware of any files that a subroutine library may access. >For example if an application for updating the password file locks the >password file database while making the update, and then calls >getpwnam(3) to retrieve a record, the lock will be lost because >getpwnam(3) opens, reads, and closes the password database. The database >close will release all locks that the process has associated with the >database, even if the library routine never requested a lock on the data- >base. Another minor semantic problem with this interface is that locks >are not inherited by a child process created using the fork(2) function. >The flock(2) interface has much more rational last close semantics and >allows locks to be inherited by child processes. Flock(2) is recommended >for applications that want to ensure the integrity of their locks when >using library routines or wish to pass locks to their children. http://leaf.dragonflybsd.org/cgi/web-man?command=fcntl§ion=2
