Following up on the comments to my four suggestions.
On option a:
Mark Bendetto wrote:
>> a) Do not install the interrupt handler for any networked read only
>> operation. We must have the interrupt handler for file:///
>> operations, or else BDB gets mad. Using this option, the OS will
>> just kill svn right at the interrupt point. We aren't modifying
>> the working copy or a local repository so nothing much should be
>> hurt. However, it may be difficult for the initial command line
>> part to tell what is a network operation and what isn't.
>
>I think this is a non-starter, since some operations may or may not
>access the network.
On option b:
Branko ??ibej wrote:
> kfogel@collab.net wrote:
>
> >Josh Pieper <jjp@pobox.com> writes:
> >
> >
> >> b) Temporarily disable the interrupt handler during possibly hanging
> >> network operations. It could be tricky, because it's hard to tell
> >> what could be allocated in pools that won't be cleaned up. This
> >> also seems like a very naughty thing for a library to do.
> >
> >I think (b) may be feasible, actually.
> >
> >
> It's not thread-safe, so you can't do it in the library.
On option c:
Mark Bendetto wrote:
>> c) Make subversion multi-threaded and push off all possibly hanging
>> network operations into other threads. Very complicated, but I'm
>> including it for completeness.
>
>
>I think the cmdline utility should remain single threaded if at
>all possible. Threading is evil.
Is the verdict on b final? If so, it seems that our only choice is to
ignore this take the (misnamed) option d.
Josh Pieper wrote:
> c) Do nothing... a user may need to use kill -9 in order to
> interrupt svn if a network operation hangs.
>
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 4 20:45:33 2004