Path: utzoo!attcan!uunet!ateng!chip
From: chip@ateng.ateng.com (Chip Salzenberg)
Newsgroups: comp.unix.xenix
Subject: Re: Mandatory locking (was Re: the 'l' permission)
Keywords: mandatory locking; Xenix seems broken
Message-ID: <1988Nov29.101509.285@ateng.ateng.com>
Date: 29 Nov 88 15:15:05 GMT
References: <71@attibr.UUCP> <4594@ptsfa.PacBell.COM> <483@auspex.UUCP> <1988Nov26.220052.19423@ateng.ateng.com> <5317@polya.Stanford.EDU>
Organization: A T Engineering, Tampa, FL
Lines: 37

According to shap@polya.Stanford.EDU (Jonathan S. Shapiro):
>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.

Quite true; but the fine print also states that mandatory locking will take
effect *only* for files with the setgid bit set, as is now done by System V
Release 3.  In contrast, Xenix 2.2 file locking is always mandatory for
*all* files, regardless of their modes.  This behavior is *not* SVID-
compliant.

>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.

Deadlock has little to do with the difference between mandatory and advisory
locking.  In fact, "a program written to the SVID" (Smail 3.1, which I am
alpha testing) *did* hang because of SCO 2.2 mandatory locking.  Consider
the scenario:

        A parent process with an exclusive lock on a file forks. (File locks
        are *not* inherited.) The child tries to read the file.  The child,
        written for advisory locking, does not expect to hang.  However,
	under SCO Xenix 2.2 mandatory locking, it *does* hang.

        Result: the child is waiting for the parent to unlock it; meanwhile,
        the parent is waiting for the child to exit!  The deadlock involves
        more than just locking, so EDEADLOCK is *not* returned.  Instead,
        both processes wait forever.

Oh well.  At least they fixed it in 2.3.
-- 
Chip Salzenberg              or 
A T Engineering             Me?  Speak for my company?  Surely you jest!
	   Beware of programmers carrying screwdrivers.