> -----Original Message-----
> From: Branko Čibej [mailto:[email protected]] On Behalf Of Branko Cibej
> Sent: maandag 28 maart 2011 14:54
> To: [email protected]
> Subject: Re: resetting sqlite statements and cancellation
>
> 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?
The SQLite handle is stored in the svn_wc__db_t instance, which in turn is
stored in the svn_wc_context_t, which is kept in svn_client_ctx_t. So only when
the pool of the client context is recycled the database handle is closed. So,
"No: we can't wait for sqlite instance cleanup"
> > 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.
Some of the recent additions from Stephan might include comparing files to
their pristines within a db transaction. So given that this can be on network
paths we really want cancelation support here.
Or (like I suggested in an earlier mail) we can move the comparision to a
callback outside wc_db.c.
In that case wc_db just has to provide proper error handling for the callback,
which it already had to do for normal io errors.
Bert
