On 9/10/07, Erik Huelsmann <ehuels@gmail.com> wrote:
> On 9/10/07, Karl Fogel <kfogel@red-bean.com> wrote:
> > "Erik Huelsmann" <ehuels@gmail.com> writes:
> > > macro:
> > > #define svn_iter_break return svn_error_create(SVN_ERR_CANCELLED, NULL, NULL)
> > >
> > >
> > > How does it work?
> > > The iterator callbacks are called for each item in the set. (If the
> > > set is ordered, we could consider adding an optional 'from_end'
> > > boolean, to make it explicitly iterate forward or backward). If the
> > > iteration is to be cancelled, the iterator callback returns
> > > SVN_ERR_CANCELLED.
> > >
> > > Returning an error (including SVN_ERR_CANCELLED) from the iterator
> > > callback acts like the C 'break;' statement:it stops the iteration.
> > >
> > > The drivers have a *completed boolean return value which is set to
> > > TRUE if the iteration was completed successfully, or FALSE otherwise.
> > >
> > > The iterator driver return value is the one returned by the iterator
> > > callback, except for SVN_ERR_CANCELLED in which case the driver
> > > returns SVN_NO_ERROR.
> >
> > +1
> >
> > Maybe don't overload SVN_ERR_CANCELLED for this, but instead use a
> > dedicated, self-documenting error code -- SVN_ERR_ITER_BREAK or
> > something.
>
> Good point: It might be returned while (accidentally) being in a loop.
>
> > I'm a little worried about using an error object as the "stop" marker
> > at all. When we have nested iterations, the inner iteration will end
> > up generating lots of error objects. True, they will be cleared, but
> > there's some overhead to just allocating something in the global pool.
>
> > The only alternative I can think of would be that all iter '*_cb_t'
> > functions would have a boolean '&stop' parameter, which they set to
> > true when they want to break out of the iteration.
>
> Well, to avoid tons of parameters, I decided to use an error return.
> Also, current
>
> if (expression)
> break;
>
> constructs can be easily rewritten to
>
> if (expression)
> svn_iter_break;
>
> where svn_iter_break is a macro expanding to a return statement
> returning the required error. It would be a lot harder to implement
> the same thing when using a parameter because it can have different
> names in different functions.
>
> > (I don't have hard numbers to back up this worry, so perhaps I'm just
> > being a curmudgeon.)
>
> Well, it's definitely not the common case for most loops, but I can't
> be absolutely sure it's not ever. My feeling is that it's not though.
Thinking about this some more, I came to the conclusion this error can
be allocated in a subpool of the iterpool: it's only a communication
means between caller and callee and doesn't have to outlive the
callers' pool's lifetime.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 10 22:19:16 2007