[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 7961 - trunk/subversion/libsvn_wc

From: John Szakmeister <john_at_szakmeister.net>
Date: 2003-12-11 03:12:47 CET

On Wednesday 10 December 2003 12:29, Philip Martin wrote:
> John Szakmeister <john@szakmeister.net> writes:
> > Again, whether or not it was allocated in the pool or not isn't the issue
> > here. It attempting to reuse a resource that you said you were finished
> > with.
> You are trying to impose API rules that are not in the present code.
> Originally, libsvn_wc was written without access batons or caching and
> it's speed was a significant problem. By the time the batons and the
> caching were introduced there was a lot of complicated wc code, and
> the batons were introduced without attempting to rewrite the code. The
> resulting API is more or less accidental.


> Try thinking of svn_wc_adm_close as "unlock" rather than as "destroy".
> It's the pool lifetime that determines memory validity, the close
> function simply removes locks and log files.

This was actually my concern. That is, if we are using these batons after
we've closed them (removing the locks), and then try to use them again to
re-acquire a lock on a child directory/file. If we're protected against
this, then I'll stop worrying. Otherwise, it looks like we have potential to
lose atomicity in certain cases. I've actually been trying to track one such
case, but have not been able to successfully determine whether it's really a
problem or not. It appears that in copy-test 9, we end up calling
adm_retrieve() on a write baton that's been closed though.

Would there be a problem if I document the fact that it's safe to do read-only
operations on the baton, such as svn_wc_adm_access_path()? My confusion
arised from the fact that the name of the function, svn_wc_adm_close(),
implies that I shouldn't use the baton after this is called.

I'm sorry for spamming the list for what seems/is a meaningless issue. I've
been bitten in a nasty way before from subtlies like this, and I don't care
to see anyone suffer through the headaches of it.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 11 03:08:24 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.