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>