chu...@picnic.mat.net (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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
