From owner-freebsd-hackers Tue Aug 24 1:19:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 81A3014CF3 for ; Tue, 24 Aug 1999 01:19:29 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id LAA57424; Tue, 24 Aug 1999 11:18:43 +0300 (EEST) (envelope-from will) To: chuckr@picnic.mat.net (Chuck Robey) Cc: grog@lemis.com, hackers@freebsd.org Subject: Re: Mandatory locking? References: <86zoziwp88.fsf@not.demophon.com> From: Ville-Pertti Keinonen Date: 24 Aug 1999 11:18:42 +0300 In-Reply-To: chuckr@picnic.mat.net's message of "23 Aug 1999 18:34:34 +0300" Message-ID: <86so59k2vx.fsf@not.demophon.com> Lines: 44 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG chuckr@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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message