[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 6161 - trunk/subversion/libsvn_fs

From: <kfogel_at_collab.net>
Date: 2003-06-06 16:18:36 CEST

Branko Čibej <brane@xbc.nu> writes:
> > Cool Karl, now you can defer to Brane on this:-)
> >
> > Brane did you look at the "[PATCH] deadlock fix?" thread?
>
> I did -- afterwards. :-(
> It doesn't change my opnion, though.

I agree there's an interface problem here, at least.

One way or another, svn_fs__retry_txn() now depends on finding a
particular error if there's a deadlock. That error could be on top,
or it could be farther down in the error list. But either way, the
interfaces of the callees need to state that they could return
DB_DEADLOCK, and state how they return it -- either directly, or
wrapped.

Right now, they don't do either. As far as I know, functions
sometimes promise to return a particular error under certain
circumstances -- but they never just say that a particular error will
be "somewhere in the returned error list".

And none of the functions in libsvn_fs/bdb/*.h say anything explicit
about returning SVN_ERR_FS_BERKELEY_DB_DEADLOCK right now!

Frankly, I'd be happy with either solution, as long as it were clearly
documented. Promising to return deadlocks directly, not just
somewhere in the error list, would be a bigger code change, but it
might be cleaner in the long run. (I can't seem to convince myself
firmly that one way is better than the other; it's very
Necker-cube-ish right now.)

+1 on Joe's commit of rev 6161, though. There was a bug, and he fixed
it. We can certainly tweak the fix, if we decide to.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 6 17:03:37 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.