Mandatory locking (was Re: the 'l' permission)

[Chip Salzenberg]

According to shap at 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             <chip at ateng.com> or <uunet!ateng!chip>
A T Engineering             Me?  Speak for my company?  Surely you jest!
	   Beware of programmers carrying screwdrivers.