Greg Hudson <ghudson@MIT.EDU> writes:
> This approach seems very dangerous. It works for the two things we
> currently do to handle errors (ignore them, or pass them back to the
> caller, perhaps annotated), but any more complicated recovery operations
> must obey the terrible constraint that they must not call any routine
> which might ignore an error in the process of its operation, or the error
> being handled becomes invalid.
>
> Allocating a separate pool for each error might seem costly because of the
> 8K minimum, but really, that space will be reclaimed pretty quickly no
> matter what happens to the error.
Ah, that's it! Thank you, Greg. I was suspicious of it myself, but
was unable to put my finger on why it was important to allocate each
error in its own pool (several of us discussed this change off-list,
but we couldn't think of the reason).
Actually, I'm pretty sure we had this whole discussion when we
invented svn_error_create(), and made the decision to create a
separate pool for this very reason. But then we didn't record why,
and I forgot. :-)
Fortunately, reverting just that portion of the change is very easy:
simply revert the mod to make_error_internal() (but add a comment this
time!), and [un]rename svn_error_clear_all() to svn_error_free(). The
calls can stay the same -- that part of the change is still good.
I'd like to revert as described above, but does anyone have more
thoughts on this first? It can certainly afford to wait a day or
two...
Thanks for the eyes, Greg,
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 10 01:19:48 2002