On Thu, 6 May 2010 15:06:54 -0400 (EDT) "Matt W. Benjamin" <[email protected]> wrote:
> The intention is to indicate that a lock is really a lease from the > server, not to encourage the server to be capricious in recalling > locks. Perhaps there's some grace concept missing when certain types > of locks are outstanding, however? The delegation concept did provide > for this. Yeah, I didn't mean to say the draft is implying they'll be revoked often; I'm just wondering what our failure mode is. I don't see how you can really avoid unhappiness: say you fcntl() lock, write(), fsync(), and write() again. If the lock gets revoked for whatever reason between the fsync() and the write()... it seems like you're screwed no matter what you do. But if we return errors the second write (and subsequent accesses) or something, perhaps we only do as badly as a disk crash? > > Also, what interfaces have atomic lock upgrades? I thought POSIX > > ones didn't, but perhaps I'm remembering incorrectly... or are there > > Windows ones that have this? > > I think a subset of POSIX interfaces does assume it, see OpenGroup > 2004's description fcntl. The situation with Windows is I think more > complicated, there may need to be a note on it. Everything I've read from them seems... vague. >>> Before a successful return from an F_SETLK or an F_SETLKW request >>> when the calling process has previously existing locks on bytes in >>> the region specified by the request, the previous lock type for each >>> byte in the specified region shall be replaced by the new lock type. -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
