[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: resetting sqlite statements and cancellation

From: Greg Stein <gstein_at_gmail.com>
Date: Mon, 28 Mar 2011 08:13:56 -0400

Stepping back... should cancellation even be in the API? When it was first
designed, I never imagined any function taking long enough to require a
cancel func. That would be left to callers, since each function would be

And what happens with the transaction here?

And is it really expected for this function to run for more than a second?
On Mar 28, 2011 8:06 AM, "Stefan Sperling" <stsp_at_elego.de> wrote:
> We have this pattern in several places within wc_db:
> svn_sqlite__get_statement(&stmt, ...)
> svn_sqlite_step(&have_row, stmt);
> while (have_row)
> {
> if (cancel_func)
> SVN_ERR(cancel_func(cancel_baton));
> /* do stuff */
> svn_sqlite_step(&have_row, stmt);
> }
> svn_sqlite_reset(stmt);
> So a cancellation handler can return without resetting the SQL statement.
> This is probably not an issue with the CLI client which will just exit.
> But what about GUI clients? If the user clicks a cancel button and tries
> another operation that reuses the statement, will there be a problem?
> If so, what's the best way to solve this?
> I think it would be ugly to check the return value of cancel_func
> What about a convenience SVN_ERR-like macro that also accepts a statement
> and resets it in case an error is thrown?
> if (cancel_func)
> SVN_ERR_RESET_STMT(cancel_func(cancel_baton), stmt);
Received on 2011-03-28 14:14:27 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.