Garrett Rooney wrote:
> On Thursday, September 12, 2002, at 05:34 PM, Philip Martin wrote:
>
>> Garrett Rooney <rooneg@electricjellyfish.net> writes:
>>
>>>> Either way, the interaction with a multi-threaded Subversion client
>>>> needs to be considered, even if it's only to document what happens.
>>>> E.g. to say that svn_set_cancelation_handler affects all threads or
>>>> that svn_async_cancel affects one thread.
>>>
>>>
>>> that's a tough question. i'm tempted to say that svn_async_cancel
>>> effects all threads, but i imagine it might be nice to have it only
>>> effect the current thread...
>>
>>
>> Assuming svn_async_cancel sets some global state, probably just a
>> flag, the question then is when does it get reset? Does the SVN_ERR
>> macro reset it after deciding to generate an error? Does the client
>> have to call svn_async_clear?
>
>
> i'm leaning towards having the client call svn_async_clear, since
> otherwise, you could get in the situation where SVN_ERR reset the
> flag, but the error that was returned was ignored by something further
> up the call chain (but still inside an svn function). i believe there
> are places where we do ignore errors explicitly, so it could
> theoretically happen...
If SVN_ERR detects a cancelation, it must return an ERR_CANCELED error
(perhaps wrapping the original error in that, but maybe not). That
implies that SVN_ERR should check if the incomng error code is already
ERR_CANCELED. It also implies that all places where we migh ignore
errors have to be checked; cancellation shouldn't be ignored.
Sure, that's a bit more work than just adding the cancellation error...
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 13 00:12:00 2002