On Sat, 6 Nov 1999, Dmitrij Tejblum wrote:
> Brian Fundakowski Feldman wrote:
> > There were zero comments about what order things happen in; in fact,
> > the ordering in this case is Just Plain Lame (TM). It's much more
> > correct to explicitly check for fp->f_count == 1.
>
> Not sure what you mean. The commit clearly states that POSIX and BSD
> locking intentionally handled in different ways here. Frankly, I see
> nothing lame in the ordering. The second VOP_ADVLOCK just should be
> moved to fdrop().
Yes, but you implied that there was some part of the commenting that
I must have missed in rev.1.68, but there was nothing about that. I
think I'll get an okay from bruce and move the unlock to fdrop(); I
have still been pondering which is more correct, actually.
>
> > > BTW, I have another little concern with that commit: It make possible for
> > > last close() of a file descriptor to return 0 instead of the error from
> > > VOP_CLOSE(), and the error from VOP_CLOSE() to be ignored.
>
> When a process do closef() on a descriptor "held" by another process
> (by fhold(), e.g. the process do read() on the descriptor), it will
> just return 0 without the call to fo_close(). Then, when the other
> process drop the descriptor, fdrop() call fo_close() but the error is
> thrown away. No?
Yes, this is what I thought you could have meant. But would you
rather lose that error in a corner case or do locking on the fd/fdtable
or just let the system crash in that case? I'm open for a better solution.
>
> Dima
>
>
>
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED] `------------------------------'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
