From owner-freebsd-hackers Sun Aug 22 17:33:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id DA3D914C23; Sun, 22 Aug 1999 17:33:54 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA00909; Sun, 22 Aug 1999 17:31:44 -0700 (PDT) (envelope-from dillon) Date: Sun, 22 Aug 1999 17:31:44 -0700 (PDT) From: Matthew Dillon Message-Id: <199908230031.RAA00909@apollo.backplane.com> To: Greg Lehey Cc: FreeBSD Hackers , FreeBSD Committers Subject: Re: Mandatory locking? References: <19990823095310.A83273@freebie.lemis.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Questions: : :1. Do we have some form of mandatory locking? If so, what is it? No we don't, unless you count the ad-hoc lockout in the master/slave pty interface :-). :2. Would it make sense to implement System V's fcntl semantics? : They're rather tacky: you set the setgid bit and reset the group : exec bit of the file permissions. Ugh. Yuch. No, nothing to do with permission bits, not for something this convoluted! :3. Alternatively (or additionally), would it make sense to have an : additional fcntl function which performs mandatory locking? : :I think that it's probably a good idea to implement (3), and also to :do (2), possibly subject to a sysctl knob. : :Greg Well, #3 can't be mandatory if you have to make a fcntl call! You mean have one program make a fcntl call that causes other programs to return an error or block if they try to open that file while the first program holds an open descriptor? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message