On 28.03.2011 14:13, Greg Stein wrote:
> 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.
As an example, I can cite that recursive proplist that I turned upside
down some time ago. On a large working copy, it takes quite a bit of
time, so it checks for cancelation between callbacks. Of course it does
that only while reading from the temporary table of intermediate
results, so that's per-connection and doesn't affect the wc-db proper.
> That would be left to callers, since each function would be
> short/atomic/quick.
>
> And what happens with the transaction here?
I'd imagine clearing some scratch pool will cause the sqlite handle to
be closed, which should roll back any pending transactions?
> And is it really expected for this function to run for more than a second?
I don't know about "this" specifically, but certainly "some" will.
-- Brane
> On Mar 28, 2011 8:06 AM, "Stefan Sperling" <s...@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);
