Errors in the global pool

[Greg Hudson <gh...@MIT.EDU>]

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

Re: Errors in the global pool

[cm...@collab.net]

Greg Hudson <gh...@MIT.EDU> writes:

> On Thu, 2002-10-24 at 11:49, Karl Fogel wrote:
> > +1.  We do have a few places where we consume specific errors as part
> > of normal operations (such as finding the top of a repository), but
> > even these rarely happen in loops.  I think the simplification is well
> > worth the extra expense.
> > 
> > Greg H, do want to do it?
> 
> I'll do it (hopefully), but probably not for a couple of weeks.  I'm in
> the middle of some... other work.

Greg, can you file an issue with this plan?  If in a couple of weeks
that issue is still open and is not STARTED by someone, you could dive
right in.  Else, this is the kind of change that really anyone could
do, I imagine.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Errors in the global pool

[Karl Fogel <kf...@newton.ch.collab.net>]

Greg Hudson <gh...@MIT.EDU> writes:
> > Greg H, do want to do it?
> 
> I'll do it (hopefully), but probably not for a couple of weeks.  I'm in
> the middle of some... other work.

Heh, nice... pause.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Errors in the global pool

[Greg Hudson <gh...@MIT.EDU>]

On Thu, 2002-10-24 at 11:49, Karl Fogel wrote:
> +1.  We do have a few places where we consume specific errors as part
> of normal operations (such as finding the top of a repository), but
> even these rarely happen in loops.  I think the simplification is well
> worth the extra expense.
> 
> Greg H, do want to do it?

I'll do it (hopefully), but probably not for a couple of weeks.  I'm in
the middle of some... other work.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Errors in the global pool

[Karl Fogel <kf...@newton.ch.collab.net>]

+1.  We do have a few places where we consume specific errors as part
of normal operations (such as finding the top of a repository), but
even these rarely happen in loops.  I think the simplification is well
worth the extra expense.

Greg H, do want to do it?

-K

Ben Collins-Sussman <su...@collab.net> writes:
> In other words, svn_error_create() would simply call
> apr_pool_create(NULL)?
> 
> >   * 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.
> 
> I like this, very clean indeed.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Errors in the global pool

[Ben Collins-Sussman <su...@collab.net>]

Greg Hudson <gh...@MIT.EDU> writes:

>   * svn_error_create() and friends would no longer need to take a pool
>     argument.

In other words, svn_error_create() would simply call
apr_pool_create(NULL)?

>   * 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.

I like this, very clean indeed.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org