[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: permissions (and other) problems

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2002-09-12 23:10:22 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.