Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 05 Jun 1998 10:59:55 -0700
From:      Julian Elischer <julian@whistle.com>
To:        Nick Stoughton <nick@relston.co.uk>
Cc:        Hackers@FreeBSD.ORG, Jason Zions <jazz@opennt.com>, mckusick@mckusick.com
Subject:   Re: POSIX standards.. fixing breakage?
Message-ID:  <3578321B.62319AC4@whistle.com>
References:  <000201bd9054$991477f0$7ce749c2@nick.relston.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
Nick Stoughton wrote:
> 
> > -----Original Message-----
> > From: julian@whistle.com [mailto:julian@whistle.com]
> > Sent: Thursday, June 04, 1998 11:20 PM
> > To: nick@usenix.org
> > Subject: POSIX standards.. fixing breakage?
> >
> >
> > As you seem to be watching teh POSIX standards, could you let me know
> > what you would suggest as a path to take in stating or supporting
> > an effort to fix things that are obviously broken in present
> > posix standards.
> >
> > ?
> Well, there are several answers to this.
> 
> First, we are actively considering a full revision of POSIX.1,
> possibly in conjunction with The Open Group updating the Single
> Unix spec. Such "repairs" would be considered in that project.

thank god..

> 
> However, now it is in the standard, there is existing industry
> practice working with it. This means we are unlikely to change
> the fundemental way an interface works. But, in a case where there
> was an alternative way of specifying it, we might introduce
> a new alternative interface that behaved differently.

an added flag either for the whole process or per file descriptor
"LOCK_FD" (or something) that had to be specifically set would be fine.

> >
> > In particular "Posix file locking"
> > I have never yet met a single person who believed that the posix
> > file-locking was less than "brain dead".
> > THis particular standard has led to the introduction of more
> > obscure bugs and the bloating of more code than one would believe
> > possible.
> >
> > The main problem is:
> > Locks are per file descriptor, except in the case where you close on of
> > the file descriptors, and the locks go away on all teh other file
> > descriptoors you have to that file.
> >
> > There has to be a way to get a change to this.
> >
> The standard says what it says. We can't change that. But we can add
> to it -- perhaps a flag you can set via fcntl for persistent locks.
> Actually, it may just be that one of the realtime subgroups is doing that
> already; I'll try and check.

thanks

On the topic I quote from the BSD4.4 man page..
-------------
This interface follows the completely stupid semantics of System V and
IEEE Std1003.1-1988 (``POSIX'') that require that all locks associated
with a file for a given process are removed when any file descriptor for
that file is closed by that process.  This semantic means that applica-
tions must be aware of any files that a subroutine library may access.
For example if an application for updating the password file locks the
password file database while making the update, and then calls getpw-
nam(3) to retrieve a record, the lock will be lost because getpwnam(3)
opens, reads, and closes the password database.  The database close will
release all locks that the process has associated with the database,
even
if the library routine never requested a lock on the database.  Another
minor semantic problem with this interface is that locks are not
inherit-
ed by a child process created using the fork(2) function.  The flock(2)
interface has much more rational last close semantics and allows locks
to
be inherited by child processes.  Flock(2) is recommended for applica-
tions that want to ensure the integrity of their locks when using
library
routines or wish to pass locks to their children.  Note that flock(2)
and
fcntl(2) locks may be safely used concurrently.
------------

You should see the internal gymnastics that the kernel has to go 
through to implenment this un-natural act. (Because  locks are 
per file open in all cases except for 'close')


> >
> > julian
> >
> I will note this for discussion in the revision project.
> 
> Another approach, if you have enough people (about 4-5), might be to
> undertake a new project yourself. This would allow you to produce
> a new "POSIX File Locking" standard, which is stand-alone. If you
> would like to know more about how to do this, Jason Zions
> (jazz@opennt.com) is both chair of the working group responsible
> for POSIX.1 and chair of the committee that reviews new projects
> and advises them. I am also a member of both these groups.

I would certainly be interrested. I'm sure that people like 
Kirk MncKusick and Eric Allman would have things to 'say' about it,
and the guys doing SAMBA have real headaches trying to 
get MSDOS locking semantics to make sense in the present framework.
The Netatalk Guys have also indicated  an interest in getting MAC
file-locking interacting with Unix locks,
and of course there is NQNFS 'Leases' and Windows "OpLocks"
that need to interract.


> 
> Hope this is useful

Very, thankyou..

> --
> Nick Stoughton

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3578321B.62319AC4>