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

Re: Issue #1586: Cancellation during gethostbyname() and connect()

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2004-10-01 15:45:05 CEST

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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.

 e) Can't our interrupt handler choose to terminate the application immediately if it wants to, by raising an Abort (or similar) signal? If so, we could introduce something like this behaviour: If your Ctrl-C hasn't taken effect, then you can issue another Ctrl-C which will abort the application immediately. The Ctrl-C handler would do something like the following:

   + If cancellation has already been requested at least once, then abort the application (by raising an Abort signal or something similar).

   + Otherwise, just note that cancellation has been requested (as it does now).

Would this solution actually work during the type of network wait in question?

(It could easily be modified to require that you wait at least (say) 10 seconds before the second Ctrl-C, or other variations.)

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 1 15:46:39 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.