Re: [BUG] Mutex is destroyed when clearing top level pool, WAS: RE: svn commit: rev 2017 - trunk/subversion/libsvn_subr

"Sander Striker" <striker@apache.org> writes:

> There is a difference between debug and production. Your patch
> only addressed the debug version.

I don't understand. There is no bug in the production version, the
mutex in the pool is not even created.

[snip]

> > This patch recreates the mutex. That works fine in Subversion but
> > then Subversion only has one thread! What is this mutex for? It's
> > used in apr_pool_walk_tree so that threads can safely access pools
> > used in other threads. Now consider what happens when a pool gets
> > cleared, the pool cleanup handlers destroy the mutex and the pool
> > free's the memory occupied by the mutex. Nowhere does the code
> > consider that another thread might have the mutex locked. Nowhere
> > does the code consider that another thread might be blocked waiting to
> > lock the mutex. I don't understand how this can work. Until the pool
> > has been removed from its parent's list of children the mutex cannot
> > be destroyed.
>
> This is all correct. I thought it was general knowledge that if you
> go around clearing/destroying a pool in one thread and using it in the
> other, you are asking for trouble. I think we need to document this,
> but I don't see it as something we should fix.

Again I don't understand. By "using it" are you referring to the
debug only functions? The ones mentioned in the comment above the
mutex creation? What is this mutex for if not to allow multiple
threads access to the pool tree?

-- 
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org