[EMAIL PROTECTED] (Chuck Robey) writes:
> On 23 Aug 1999, Ville-Pertti Keinonen wrote:
> > And even without otherwise incorrect behavior, if you have a program
> > that doesn't use any locking and another one that uses mandatory
> > locking to prevent races with the non-locking program, the mere
> > existence of the locking program does not prevent multiple non-locking
> > programs from generating similar conditions.
>
> That's very odd, I thought the idea behind mandatory locking was to
> completely eliminate the possibility that a program could do what you're
> saying; all programs would *mandatorily* be forced to do locking to
> access the resource.
I don't know what the textbook definition for mandatory locking is,
but was assuming (particularly considering the proposal to use a fcntl
interface) that by mandatory locking, Greg was referring to a "harder"
lock than current advisory locking, one that had to be instantiated
explicitly but would not only lock out other attempts to lock, but all
other attempts to access the file.
The further messages in this the thread seems to indicate that
different individuals have different definitions for mandatory
locking... I'd still assume that marking a file to be accessible by
only one process at a time is *not* what is being discussed.
Particularly since it is not even clear what this would mean for
forked processes, dup, sending file descriptors over local sockets
etc.
Note that my arguments earlier don't apply in a case where you might
want to e.g. ensure consistency for non-locking programs with
read-only access, with the only program with privileges to modify the
data making the data inaccessible during updates. This is a scenario
where it would, IMHO, actually be quite useful to have mandatory
locking.
In any case, if shared (open) access is allowed, such a feature can
introduce semantic changes to read/write system calls - normally,
read/write can never return EAGAIN or block for unlimited amounts of
time on regular, local files. EAGAIN is not that much of a problem,
as it requires explicitly setting O_NONBLOCK, but blocking can
introduce new deadlocks.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
