On Wed, May 29, 2013 at 6:03 PM, Blair Zajac <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.
To be perfectly clear, I'm well aware that many folks have written some
particular library modules in C++ over the years. Perhaps I could see a
case for a new FS layer written in C++ - those who don't have a modern C++
compiler can still use fsfs. (We go from 2 to 1 and back to 2 FS impl's
again!) Rewriting libsvn_client or libsvn_wc in C++ is where I think
things would just breakdown if we tried to do it in a piecemeal approach -
at that point, everything underneath would have to change to C++. And, we
know how much fun it was to rewrite libsvn_wc the last time. -- justin
Received on 2013-05-30 03:17:46 CEST