On Jan 24, 2007, at 8:04 AM, Robert Engels wrote:
Curious, I guess I don't understand the BSD disclaimer. The
application should not need to track any of this. The OS should be
tracking open FD and locks for the process, and when it closes a FD
on behalf of a process it should also remove the locks.
You're right. A less aggressively truncated excerpt should make
things clear. Here's the whole paragraph:
This 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
getpwname(3) to retrieve a record, the lock will be lost because
getpwname(3) opens, reads, and closes the password database.
The data-
base close will release all locks that the process has
associated with
the database, even if the library routine never requested a
lock on the
database. 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. Note that flock(2) and fcntl(2) locks may be safely
used con-
currently.
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
