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, 08 May 2014 17:53:09 GMT
Am Freitag, 2. Mai 2014, 19:39:52 schrieb Branko Čibej:
> >> 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.
> A pool debug option that does something like that would be welcome.
> But it shouldn't be turned on by default, or pool allocation
> performance is likely to go down the drain.

It turns out one does not need a mutex for this at all. 
apr_atomic_cas32() is enough. I agree that this should not be enabled 
by default, but I still hope that it is fast enough to be included in 

Does anyone have any suggestions how to call such an option? Maybe

 --enable-pool-concurrency-checks or
 --enable-pool-concurrency-debug ?

> > 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.
> I'm very sceptical of such an approach. Serializing access to a pool
> like that is likely to be a band-aid for bad API design; if you
> need a pool shared across threads, e.g., to implement a cache, then
> serializing allocation is likely to be the least of your concerns,
> and not at all the same as serializing access. For the latter you
> need explicit locking, and doing that at the pool level is probably
> wrong.
> In other words, a feature like that would only help someone who
> takes a very naïve (or lazy) approach to software architecture. We
> really don't have to support that. :)

I think in some cases where a special pool is used very seldomly, it 
could be an acceptable solution. But it would come with the danger 
that people would just switch to this type of pool instead of fixing 
the actual bugs.

View raw message