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

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

From: Josh Pieper <jjp_at_pobox.com>
Date: 2004-07-02 14:42:09 CEST

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


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 2 14:43:20 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.