--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 19, 2004 at 02:19:57PM +0900, YAMAMOTO Takashi wrote:
> > >=20
> > > actually, there's no much differences.
> > > if vn_lock(LK_RETRY) can fail,
> > > all callers should check it and shouldn't unlock the vnode after an e=
rror.
> > > it's better to make sure that vn_lock(LK_RETRY) won't fail rather than
> > > letting all callers check error conditions, IMO.
> >=20
> > Well, then I guess we'll have to disagree. I'm always concerned by what=
=20
> > happens if a routine that "can't fail" realizes it is going to fail. It=
=20
> > either has to do something like panic, or it has to pretend things are =
ok.=20
> > If instead it can fail, it can tell the upper layers that something is=
=20
> > wrong. They can choose to not do anything, but they've been told.
>=20
> there's no problem to having a routine that won't fail.
> and there's no problem not to checking its failure.

I agree that there's no problem in having a routine that can't fail, nor=20
ignoring any "error" return value in such a case. I still feel, though,=20
that vn_lock() isn't that routine.

> i can understand your concern, given that vnode lock's implemention is
> somewhat complicated unnecessarily.
> it's better just to simplify it.

Well, I'll be happy to hear your simplification when you propose it. But=20
as I said above, I don't think just making vn_lock() never fail is the=20
way.

Also, I think a lot of the complexity in the vnode system is there to=20
handle the many different issues it is forced to face. I'm always a bit=20
hesitant about changing it, lest we painfully rediscover a corner case the=
=20
code got right before (but not after) a change.

> > Also, consider something like a distributed file system with a lock=20
> > manager (as in a separate server). Say you can't contact the lock manag=
er.=20
> > Do you really sit there in uninterruptable sleep for ever? Yes, how and=
=20
> > when you decide to give up is something the admin decides (as it should=
=20
> > be). But the scenario shows a reason to have vn_lock(LK_RETRY) fail.
>=20
> no.
> such a distributed filesystem is broken in design, IMO.
> it's a horrible idea to use vnode locks for remote locking.

Maybe, maybe not. One advantage of our node locking protocol is that the=20
locking is visable to the caller. So the caller can use the lock to=20
perform a sequence of actions atomically.

> btw, please answer my first question.
> are you going to add checks on every vn_lock(LK_RETRY)?

Not at the present time. While I think that would be a good and correct
thing, I do not have the time nor energy to change each occurrence.

Take care,

Bill

--rwEMma7ioTxnRzrJ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFA1MkFWz+3JHUci9cRAuX5AJ9m1lLA8OeGdIp7bACEceAlChdsDACfVSLF
F8SJxZTUaB9NC9mHw9H/iuc=
=MVMM
-----END PGP SIGNATURE-----

--rwEMma7ioTxnRzrJ--