Philip Martin wrote:
> Garrett Rooney <rooneg@electricjellyfish.net> writes:
>
>
>>I like this idea.
>>
>>The client calls some function (svn_set_cancelation_handler() ?) which
>>sets the function to be called by SVN_ERR(). then SVN_ERR() can call
>>it (if it's been set) and if so, it returns the error.
>>
>>
>>We can't just have a global variable, it's got to be something that
>>can be controlled by the client application, but other than that i
>>really like this idea.
>
>
> Another way would be to provide a function that the client
> application's signal handler calls to indicate that a cancellation
> should occur, e.g. have svn_async_cancel() called by the signal
> handler rather than svn_set_cancelation_handler() by the main
> code. That might make for a more efficient SVN_ERR implementation.
good idea! i like that a lot more than calling a user defined function
every time we use SVN_ERR().
> 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... of course, threads and signals don't work
too well together anyway...
any opinions?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 12 23:10:58 2002