On 5/29/13 6:17 PM, Justin Erenkrantz wrote:
> On Wed, May 29, 2013 at 6:03 PM, Blair Zajac <blair_at_orcaware.com
> <mailto:blair_at_orcaware.com>> wrote:
>
> Yup, I've had lots of issues with this. Putting C++ pool wrappers in C++
> classes and having them destroy in the correct order can be tricky to get
> right (lots of core dumps in our internal RPC server). One of the nice
> things about moving to C++, assuming we don't use pools, is that one could
> stop thinking about memory management.
>
>
> I don't see how you can have a clean C++ implementation as we expose pools in
> the C API. I just think we're going to bring a world of hurt upon us all if we
> try to do a wholesale rewrite of C++ and try to shove the pool model into it.
> (The batons and callbacks all require pools with a certain lifetime - so there
> are third-party code that is relying upon the pool hierarchy being correct.)
>
> If we really wanted to go that route, the far saner (if you can call it that)
> approach is to just call it Subversion 2.0 and have a pool-free external
> API...from where I sit, I don't see much value going that far - how many years
> do we want to dedicate to 2.0? Are things ultimately so broken that we simply
> can't make Subversion better unless we go to C++? It's not a zero-cost item.
I agree it's not worth going to C++. Where I'm coming from is a frustration on
the number of times I've seen pool lifetime bugs get fixed and it would be great
to be in a language where one doesn't need to worry about that, or as much.
Blair
Received on 2013-06-02 03:52:44 CEST