> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_xbc.nu] On Behalf Of Branko Cibej
> Sent: maandag 28 maart 2011 14:54
> To: dev_at_subversion.apache.org
> 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.
Received on 2011-03-28 15:04:11 CEST