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 short/atomic/quick.
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" <[email protected]> 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 manually. > 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);
