On Fri, Jul 02, 2004 at 08:42:09AM -0400, Josh Pieper wrote:
> Part of issue #1586 is that interrupting Subversion during DNS lookups
> (gethostbyname) or when initiating a network connection (connect) is
> difficult. This can manifest itself, for instance, if network
> connectivity is lost in mid operation.
Well, connect() can be made non-blocking, and there are a few robust
asynchronous DNS implementations (one of them even written by Greg
Hudson).
The same holds for our blocking network reads and writes.
I haven't looked at Neon to see how much work it would be to
implement this, but it should be (reasonably) straightforward.
Except for the DNS (unless we go with ares/adns/etc).
>
> Since this can't be solved by adding more cancellation checks, I am
> feeling out how acceptable other solutions would be. I have a few
> possible alternatives that I have considered:
>
> 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.
>
> 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.
It is an evil thing for a library to do, but the library *could* notify
the client "starting blocking thing, you might want to remove any
interrupt handlers" and "done with blocking thing, you might want to
reinstall any interrupt handlers". This may be the easiest approach.
>
> 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.
> c) Do nothing... a user may need to use kill -9 in order to
> interrupt svn if a network operation hangs.
>
> Are there any other options and/or opinions? I'm leaning towards the
> last option, but I want to see if there are any other ideas or
> objections.
>
Well, I'd learn towards (b) or patching neon to do non-blocking things.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 2 19:11:57 2004