apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: pool owner debugging idea
Date Thu, 01 May 2014 15:38:29 GMT
Am Donnerstag, 1. Mai 2014, 06:37:04 schrieb Jim Jagielski:
> I would really appreciate subversion's input on this...
> in many many ways, they push APR to its limits, esp
> related to pools.

I don't know if subversion uses threads heavily. I suspect that the 
pattern of pools being used by different worker threads is unique to 

> Is there anyway this trylock could be conditional?
> For example, could we add some sort of flag or whatever
> that would implement this on specifically created pools?

We could do that, but I don't really see a use case. I was imagining a 
debug option that is globally switchted on by a configure option. And 
this would not be used in production, at least not unless one is 
hunting a specific bug.

What use did you have in mind? Maybe you were looking for some really 
thread-safe pools that use a mutex to serialize accesses? In this 
case, the mutex would be enabled by some flag to apr_pool_create(). 
There is PR 51392 requesting that. If you think that would be useful, 
that could be something for apr 1.6.

> On May 1, 2014, at 5:16 AM, Stefan Fritsch <sf@sfritsch.de> wrote:
> > Hi,
> > 
> > it's currently rather hard to debug issues caused by pools being
> > used by different threads. The current pool debugging options
> > don't really work if pool ownership changes during runtime (as
> > int mpm event), require specific apr_pool_owner_set() calls, and
> > apr compiled with pool debugging is significantly slower than
> > normal apr.
> > 
> > So, I had the following idea for a lightweight debugging help:
> > 
> > All pool operations are protected by mutexes. But in order to get
> > the mutex, the operations use apr_thread_mutex_trylock(). If
> > there is any contention while getting the mutex, we abort(). This
> > would only catch threading issues during relatively high load
> > when there is actual contention. But the mutex operations should
> > be relatively cheap comparted to the full blown pool debugging.
> > So maybe this feature could be even enabled by default if
> > compiled in maintainer mode.
> > 
> > Do you think this would be a good idea?
> > 
> > Cheers,
> > Stefan

View raw message