apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@apache.org>
Subject Re: pool owner debugging idea
Date Fri, 02 May 2014 17:39:52 GMT
On 01.05.2014 17:38, Stefan Fritsch wrote:
> 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 
> mpm_event.

It does, depending on context. The command-line client is currently
single-threaded, but GUI clients (e.g., TortoiseSVN or SmartSVN) are
anything but; svnserve can be multi-threaded, and mod_dav_svn works just
fine with mpm_event. Our APIs are designed to be thread-safe with
certain restrictions.

>> 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.

> 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. :)

-- Brane

View raw message