🚀 go-pugleaf

In article <5909@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>> Locking (concurrency): Locking, what locking?
>> UNIX file locking schemas are, in general, bad.
>> ...
>> A DBMS would be well off with three (3) levels of locks,
>> (operating system people LISTEN!)  ...
>
>If you database people could manage to get your act together and agree
>on something for more than 15 milliseconds, maybe we *would* listen.
>The main reason nobody wants to put database-oriented locking into an
>operating system is that no two database people agree on what they want.
>
>The existing Unix locking schemes are simple, hence often inadequate,
>because nobody wants to go through the hassle of implementing a complex
>mechanism when there is no consensus on what it should look like.

Ok, no name calling.  File locking is a feature of almost every
major operating system.  UNIX aviods the issue and I can appreciate
the reasons.  UNIX has survived, in part, because what it does it
does in a generalized way.  What is needed is a generalized view
of file locking.  Simple applications such as mail (mail is not
that simple but stuffing mailboxs is) don't need more than flock(2).
Complex applications, DBMS's and custom databases, will need
better locking.  How about range locking with arbitrary levels
and user defined conflict conditions?  This should cover all the
bases.  I can imagine how to do it as well.  If the /usr/group lockf
call could be so generalized we could have backward compatability
and forward progress.

I know it's not all that simple.  But if I did build the above
locking call, would it be accepted by the OS world?  Maybe.
-- 
C knows no bounds.
					Jeff Anton
					U.C.Berkeley
					Ingres Group
					ucbvax!anton
					anton@BERKELEY.EDU