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" <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
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);
Received on 2011-03-28 14:14:27 CEST