As we all know, when you create an error, it can't live in the pool
you have handy, because the error will be handled by some function way
down the call stack.
The status quo is that errors are allocated in a subpool of the
uppermost pool created with svn_pool_create(). Error memory can be
collected using svn_error_clear_all(), but from previous discussion,
we know that function is horribly unsafe because there might be
another error in in the process of being handled. I think we agreed
that there ought to be a function to clear a specific error, but
nobody ever implemented that.
It occurred to me recently that if we have to explicitly deallocate
errors, then we may as well allocate each error in its own pool
hanging off the global pool. It doesn't matter that subpools are
mildly expensive because errors are infrequent. (Alternatively, we
could use malloc(), but that would be inconvenient.)
This change would have some interesting ramifications:
* svn_error_create() and friends would no longer need to take a pool
argument.
* Functions would no longer have to take a pool argument simply
because they might return errors. (Though, for functions in our
API, we wouldn't want to remove the pool parameter unless we could
be sure that no reasonable implementation of the function would
want to allocate memory, not merely that the current
implementation doesn't allocate memory.)
This would be a traumatic change as far as the SWIG bindings and
svncpp (not to mention our own code base), but it would be a dramatic
simplification, and we'd certainly want to do it before 1.0 if we did
it at all.
Opinions?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 24 05:06:58 2002