On Saturday, September 14, 2002, at 03:39 PM, Philip Martin wrote:
> Garrett Rooney <rooneg@electricjellyfish.net> writes:
>
>> i thought of that, but it raises an interesting question. is it more
>> important to get the line number of where you were canceled, or to
>> have the user defined cancelation function be able to annotate the
>> error with some indication of why you were canceled? something worth
>> thinking about.
>
> Well, the client can record and report the reason independently of the
> svn_error_t. The line number information, on the other hand, once
> lost has gone for ever.
yeah, that makes sense. my current patch (attatched to this email)
goes with svn_boolean_t as the return type.
>>> Note that as far as asynchronous signals go, it doesn't really matter
>>> whether SVN_ERR calls the cancel function before or after expr, so it
>>> can be written
>>
>> i thought of that, but i figured since we've already been told to stop
>> doing work, we might as well make that check happen before we go off
>> and do any other work.
>
> You have missed that the cancel state will (usually) get set
> asynchronously. So it may not be set before calling expr, it may get
> set *during* expr, and then be set after expr. In general, it makes
> no difference whether you check before or after expr, neither one is
> more immediate, or "faster", than the other. So just pick which ever
> produces the cleanest code.
as usual, you make a lot of sense ;-)
here's what i've currently got. the patch has two known issues.
first, for some reason if i use a subpool of the main pool as the
cancelation pool, we segfault trying to allocate the cancelation error.
i have no clue why this is happening. if someone could shed some
light on the problem, i would appreciate it. second, there's one place
(that i noticed) where svn_error_clear_all is used in a function which
does not return an svn_error_t *, so we seem to be stuck not having
cancelation supported from there. i guess as long as this doesn't
happen often, it's ok, but i still don't like it.
another thing that's popped up is that if i control-c out of a long
running update, we end up leaving lockfiles all over the place, even
though we errored out with SVN_ERR_CANCELED. if someone who has more
clue about how the locking in libsvn_wc works could explain how this
can happen, i'd appreciate it. should there be an error condition
where we leave the working copy locked? would it make sense to put
checks for SVN_ERR_CANCELED in places where this kind of things could
happen?
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 16 04:51:51 2002