Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!cca!ima!johnl
From: johnl@ima.UUCP
Newsgroups: net.arch
Subject: Re: RMS v/s UNIX (non-religious)
Message-ID: <509@ima.UUCP>
Date: Tue, 12-Mar-85 23:35:21 EST
Article-I.D.: ima.509
Posted: Tue Mar 12 23:35:21 1985
Date-Received: Fri, 15-Mar-85 02:26:20 EST
Lines: 27
Nf-ID: #R:sjuvax:-91700:ima:4600005:000:1368
Nf-From: ima!johnl    Mar 12 17:42:00 1985

> My feeling is that the default should always be to prevent disaster.

(The writer was advocating very stringent default locking to avoid letting
programs read partly updated or inconsistent data by mistake.)

It depends what you mean by disaster.  In your system, it's evidently
disastrous for people to see an inconsistent view of a data base.  In my
system, it's disastrous for some gonzo to read lock /etc/passwd so that
nobody can log in.  Both are real problems, but different environments
require different approaches.

I've argued this with a lot of people, and it has become evident to me that
no simple locking scheme can do the right thing, whatever that is, in more
than a minority of circumstances.  As a result, I've become firmly attached
to the idea of locking magic cookies so that a group of programs that want
to synchronize their reading and writing can do so, while other programs
that don't understand locking do not get "file locked" errors that they
cannot deal with.

Oh, and lest you get the wrong idea, the magic cookies should be named in
the file system name space, which on a Unix system is the only real name
space there is, and is certainly the only one rich enough to deal with
private groups of locks, local groups of locks, and such.

John Levine, ima!johnl

PS:  I promise not to write any more on this topic for at least a month.