Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Jul 1997 16:05:26 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        julian@whistle.com (Julian Elischer)
Cc:        terry@lambert.org, lederer@bonn-online.com, freebsd-hackers@FreeBSD.ORG
Subject:   Re: POSIX locking ( was NFS locking)
Message-ID:  <199707012305.QAA05274@phaeton.artisoft.com>
In-Reply-To: <33B985FA.3F54BC7E@whistle.com> from "Julian Elischer" at Jul 1, 97 03:34:34 pm

next in thread | previous in thread | raw e-mail | index | archive | help
[ ... POSIX brain damage ... ]

> I suggest that we have a per-process flag that allows the locks to be 
> done per-fd.
> it would break posix, but if you had posix by default, and this 
> only if you set it, then it would still be posix complient.

I was thinking of an fcntl-based semantic overide, set on a per
fd basis.  Something like:

	int i = 1;
	fcntl( fd, F_NONPOSIX, &i);

or even

	fcntl( fd, F_NONPOSIXCLOSE, &i);

if we wanted to be anal about the meaning of the flag.

This would really be the best way to handle it, without really
breaking POSIX (default it to on).  That way the per process
semantics are still POSIX.

I could easily envision a process that was mixed POSIX and non-POSIX
I/O.  A per fd overide makes a lot more sense than a per process
overrride in that case.  Plus the file struct has to be there anyway
for you to close it or anything else, for that matter.


> such things as samba and nfslockd could flip the bit and get
> useful semantics.

Yes.  I thought that proxy locking would be useful for service
as well.  I left enough spare space in the compatability struct
that I defined for communicating the remote system ID and process ID
such that versioning could be done without having to change the struct
in an incompatible way.  The trick on versioning it for the remote
ops is that the local ops have implied field values (ie: you can't
get the lock data for a remote lock locally).  This leaves the call
binarily backward comaptible, which was the main design goal.


> Anyone think this is a TERRIBLE idea?

Nope.  8-).

					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707012305.QAA05274>