From: Bill Ricker (Bill.Ricker@eng.sun.com)
Date: 02/05/01-07:24:23 PM Z
Message-ID: <3A7F5247.957FD255@Eng.Sun.COM> Date: Mon, 05 Feb 2001 17:24:23 -0800 From: Bill Ricker <Bill.Ricker@eng.sun.com> Subject: Re: LOCKT vs. POSIX fcntl(F_GETLK,...) "Kendrick M. Smith" wrote: > > Hi all, > > The LOCKT operation returns a LOCK4denied structure if a conflicting lock > is found. This structure contains > - the owner of the conflicting lock, and > - the endpoints of the conflicting lock (i.e., offset and range) > However, the POSIX system call for lock testing, fcntl(F_GETLK, ...), must > return (in the case of a conflicting lock) > - the owner of the conflicting lock, > - the endpoints of the conflicting lock, and > - the type of the conflicting lock (i.e., whether a read or write lock) > Consequently, the protocol does not quite allow implementation of the > POSIX semantics for lock testing. The easiest solution would seem to be > the addition of a "type" field to the definition of 'struct LOCK4denied'. > Is the addition of such a field still possible at this point? Any other > suggestions? - Kendrick I've always wander if following posix semantics makes much sense here. The protocol makes the lock owner an opaque type. Presumably if the client id in the lock owner is the same as the client's clientid you could peek inside and interpret the lock owner id, otherwise it has no value at all. The client id does not identify the host in any meaningful way in general to the client either. Seems like a more useful thing that would be useful is the stateid of the lock holder. The client could bitch at the server admin that this stateid is holding the lock, and if the admin agrees to release it, he could run a command given the state id to revoke the lock. This seem easier than the user of a client giving a lock owner and a file handle to clear. But even this does not translate well to fcntl. Lock ownership is specified by a 32 bit sysid and 32 bit pid. How do you meaningfully map a 64 bit host id and an arbitrary length lock owner or a 64 bit stateid id in to an flock structure? And while we're on the subject. Why make lockt take a lock owner in the first place. If I'm interested in checking for locks, I think it reasonable that I would be interested in acquiring locks, so I should do an open and get a stateid. Seems like this would be a simpler way to go. Are there many applications that want to check for the presence of a lock and then not acquire locks? In fact why do we need lockt at all. Doesn't a compound request of lock followed by unlock suffice? Is this operation used so much as (V4 locking isn't blocking) to warrant an optimized procedure call? -- bill
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:32 AM Z CST