On Fri, Jun 01, 2012 at 06:19:58PM -0400, Michael P. Reilly wrote:
> On Fri, Jun 1, 2012 at 3:13 PM, Andreas Krey <a.krey_at_gmx.de> wrote:
>
> > Hi everybody,
> >
> > is there already a bug on this? I can't always get the svn client to
> > stop using ^C. Mostly this seems to happen with slow network I/O, like,
> > for reproduction:
> >
> > prompt> time svn checkout http://217.140.74.17/doesnotexist
> > ^C^C^Csvn: OPTIONS of 'http://217.140.74.17/doesnotexist': could not
> > connect to server (http://217.140.74.17)
> >
> > real 1m14.898s
> > user 0m0.007s
> > sys 0m0.006s
> > prompt>
> >
> > I hit ^C shortly after hitting enter, but 1) svn doesn't stop
> > and 2) doesn't even seem to care about the signal received.
> >
> > The only way to actually get rid of it is to ^Z and 'kill -9 %',
> > but this then requires a cleanup occasionally (plus the prayer
> > that the latter will work).
> >
> > Andreas
> >
>
> What release of Subversion and what is your operating system? Standard
> network has a timeout of about 120 seconds, but depending on the OS, the
> command may not be interrupt-able until that timeout.
>
I believe this is neon blocking on socket I/O for a fixed timeout and not
returning to Subversion code until after the timeout has expired.
Some signals never have an immediate effect in Subversion.
Subversion handles signals gracefully at defined points to ensure state
is cleaned up properly. When the signal is received, a flag is set that
is checked next time Subversion invokes the cancellation handler which
then cleans up state and causes an exit.
It seems using serf improves signal response time in this case, at least
with recent enough serf releases. It won't block on the socket as long as
neon does.
Received on 2012-06-02 11:15:04 CEST