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

Re: Client hangs when svnserve does not respond

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-08-03 00:25:15 CEST

Greg Hudson wrote:
> On Thu, 2005-06-23 at 09:47 -0500, kfogel@collab.net wrote:
>
>>If that's the issue, we could either:
>>
>> a) Untrap the interrupt handler during that wait.
>> b) Wait for the server in a non-blocking or semi-blocking way.
>>
>>I'm hand-waving a bit, but are there any solutions along these lines?
>
> Yeah, we could set a timeout on the socket and call the cancellation
> function between repeated read calls, assuming the cancellation function
> is available to the RA layer.
>
> That's not really the ideal solution; from the perspective of what
> system calls we generate, it would be better to make sure that the
> read() isn't set to be restartable and call the cancellation function
> when we get the EINTR. But I'm not sure if APR makes that feasible. I
> think it blithely restarts system calls under the covers without
> considering this issue.

Let the behaviour be: Ctrl-C requests an abort; a second Ctrl-C forces an abort.

The problem, as I understand it, is that in several different cases the user
can't interrupt Subversion during a system call that is taking too long. This
is because our SIGINT handler just sets a flag when they press Ctrl-C and
doesn't do anything else. We should be able to modify our SIGINT handler to
avoid that problem. It should set the flag, and then arrange that if a second
SIGINT should be received, it will unconditionally terminate the application.
It can probably do so by uninstalling itself, so that any future SIGINT has the
default handling. [*]

Please don't argue that "The user might press Ctrl-C twice in quick succession
and thereby cause an unclean abort in cases when he would have got a clean
abort if he had waited a second or three. Therefore we shouldn't do this
because that would inconvenience such users." If such considerations are
really a serious concern then there are ways to address them such as time delays.

- Julian

[*] A possible but unlikely alternative: The handler could say, "if (flag is
already set) then { abort() }". But I don't know if an interrupt handler can
abort the application; probably not, or it may depend on whether the C library
implementors consciously arranged for the "abort()" call to handle that special
case.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 3 00:26:43 2005

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.