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
