[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: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-07-04 21:26:41 CEST

On Sun, 2004-07-04 at 14:44, Josh Pieper wrote:
> Following up on the comments to my four suggestions.

Well, some more wacko ideas:

  * Add a client context callback to set up signal handlers. (The real
meaning of the callback is "we're about to do something which requires
cleanup, so try to ensure that it gets done".) Now libsvn_client can
help decide whether cleanup is necessary, and network-only operations
can be interrupted.

  * APR is screwing us on connect() by intercepting EINTR. Perhaps we
could add an interruptability flag to APR files and/or sockets. We'd
then have to perform or own retry loops, but we could check the
cancellation callback each time. (This would also help with our
prompting problem.)

  * I don't think WC cleanup ever involves making a gethostbyname()
call, although it can involve doing a variety of other things. So it
should be theoretically sort-of possible to make it possible actually
perform cleanup from within the signal handler. This idea is especially
wacko, though.

  * There's this non-portable function res_send_setqhook() which is
supposed to set a hook to be called between trials of a hostname
lookup. The actual trials themselves are not interruptable, but we
could significantly reduce the time before interrupt if we could make a
query hook check the cancellation flag. Unfortunately, in my
experiments on a Red Hat box, it didn't work; I think glibc may be
contriving to use a separate _res for gethostbyname's libresolv calls.
So in addition to being nonportable, it wouldn't help on our most
popular platform.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 4 21:27:52 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.