On Tue, 14 May 2002, Terry Lambert wrote:
> Richard Sharpe wrote:
> > Hmmm, I wasn't very clear ...
> >
> > What I am proposing is a 'simple' fix that simply changes
> >
> > p->p_flag |= P_ADVLOCK;
> >
> > to
> >
> > fp->l_flag |= P_ADVLOCK;
> >
> > And never resets it, and then in closef,
> >
> > if ((fp->l_flag & P_ADVLOCK) && fp->f_type == DTYPE_VNODE) {
> > lf.l_whence = SEEK_SET;
> > lf.l_start = 0;
> > lf.l_len = 0;
> > lf.l_type = F_UNLCK;
> > vp = (struct vnode *)fp->f_data;
> > (void) VOP_ADVLOCK(vp, (caddr_t)p->p_leader, F_UNLCK, &lf,
> > F_POSIX);
> > }
> >
> > Which still means that the correct functionality is implemented, but we
> > only try to unlock files that have ever been locked before, or where we
> > are sharing a file struct with another (related) process and one of them
> > has locked the file.
>
> Do you expect to share the same "fp" between multiple open
> instances for a given file within a single process?
>
> I think your approach will fail to implement proper POSIX
> file locking semantics.
>
> I really hate POSIX semantics, but you have to implement
> them exactly (at least by default), because programs are
> written to expect them.
>
> Basically, this means that if you open a file twice, lock it
> via the first fd, then close the second fd, all locks are
> released. In your code, it looks like what would happen is
> that when you closed the second fd, the fp->l_flag won't have
> the bit set. Correct me if I'm wrong?
>
> The reason for the extra overhead now is that you can't do
> this on an open instance basis because of POSIX, so it does it
> on a process instance basis.
OK, you have convinced me. I have looked at the POSIX spec in this area,
and agree that I can't do what I want to do.
> The only other alternative is to do it on a vp basis -- and
> since multiple fp's can point to the same vp, your option #2
> will fail, as described above, but my suggestion to do the
> locking locally will associate it the the vp (or the v_data,
> depending on which version of FreeBSD, and where the VOP_ADVLOCK
> hangs the lock list off of: the vnode or the inode) will
> maintain the proper semantics.
>
> Your intent isn't really to avoid the VOP_ADVLOCK call, it's
> to avoid making an RPC call to satisfy the VOP_ADVLOCK call,
> right?
Yes, correct. We will have to do it in the vnode layer as you suggest.
Currently we are using 4.3 and moving to 4.5, so we will have to figure
out the differences.
> You can't really avoid *all* the "avoidable overhead", without
> restructuring the VOP_ADVLOCK interface, which is politically
> difficult.
I wouldn't want to try. Too much code to change and too much chance of a
massive screw-up.
Thanks for perservering with me.
Regards
-----
Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
