Xref: utzoo comp.unix.xenix:4021 comp.unix.wizards:12943 Path: utzoo!attcan!uunet!husc6!think!ames!decwrl!labrea!polya!shap From: shap@polya.Stanford.EDU (Jonathan S. Shapiro) Newsgroups: comp.unix.xenix,comp.unix.wizards Subject: Re: Mandatory locking (was Re: the 'l' permission) Keywords: mandatory locking; Xenix seems broken Message-ID: <5317@polya.Stanford.EDU> Date: 28 Nov 88 19:58:15 GMT References: <71@attibr.UUCP> <4594@ptsfa.PacBell.COM> <483@auspex.UUCP> <1988Nov26.220052.19423@ateng.ateng.com> Reply-To: shap@polya.Stanford.EDU (Jonathan S. Shapiro) Organization: AT&T Bell Laboratories Lines: 43 Followup-To: In article <1988Nov26.220052.19423@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes: > >...and unfortunately, despite all protestations to the contrary, SCO Xenix >does *not* comply with the SVID on this topic. Even though it's called >"Xenix System V." > >Under SCO Xenix, there are three locking methods: > > locking(), a Xenix invention > lockf(), per /usr/group and in the SVID > fcntl(), in the SVID > >None, that's right, *none* of these locking methods provides advisory >locking under SCO Xenix. Even though fcntl() and lockf() MUST be >advisory to conform to the SVID. Instead, we get mandatory locking and, >therefore, deadlocks on programs written to the SVID. Actually, if you read the fine print in the SVID, you may discover that they are conforming, and that even if they aren't, your claim about conforming programs is not quite on target. In SVR2, advisory locking was introduced via lockf(2) and fcntl(2). A reading of the fine print will turn up a note indicating that this will be changed to be mandatory locking at some unspecified point in the future. In SVR3, the locking became mandatory. If SCO Xenix is SVR2-based, then it would appear that they are not SVID conforming in this regard. If they are SVR3-based then they are conforming. I don't know enough about the product to know one way or the other. One might even argue that by implementing the warning ahead of schedule they are still SVID conforming, even under SVR2. However, a program written to conform to the SVID will have no problems in either case, because the warning in the SVID commentary indicates that your program should make pessimistic assumptions about deadlock. Jonathan S. Shapiro AT&T Bell Laboratories