Greg Hudson <ghudson@MIT.EDU> writes:
> In August, Karl committed r15909:
> Fix a bug whereby connecting to a non-existent repository can cause
> apr_socket_connect() to hang non-interruptably. To reproduce, try
> 'svn co svn://svn.edgewall.com'.
> Patch by: Yun Zheng Hu <firstname.lastname@example.org>
> (Tweaked by me to use apr_socket_set_timeout instead of apr_setsocketopt.)
> Karl committed the patch with a note to the mailing list:
> However, I think I'm going to commit the latest patch. It seems like
> it is an improvement for some people, and at least not harmful for
> everyone else.
> I have three problems with this patch:
> * It doesn't reset the socket timeout after connecting, so it has
> the unintended consequence of introducing a 30s timeout in ra_svn,
> although that timeout gets unset for some operations once you go
> into a pipelined edit.
> * We should not be introducing an unconfigurable 30-second timeout
> on making network connections. The connect timeout is an OS
> decision, not a we-hardcode-it-in-Subversion decision.
> * The patch was predicated on the notion that OSX has some horrible
> bug related to interrupting blocking connects. *Lots and lots* of
> programs do blocking connects. If OSX really has or had an issue
> related to doing that (and I think we pretty much took the patch
> submitter's word for that), I don't think the answer is for every
> piece of code to change to doing non-blocking connects.
> Karl, please revert the change.
On the basis of your comments, it sounds like acceptable solutions
would be to:
1) Make the (now-temporary) timeout a configurable value and reset
the timeout after successfully connecting, or
2) Revert r15909.
I don't have time to do (1) and test it thoroughly, so I've done (2)
instead, in r17697. But I'd like to know if you think (1) would be a
www.collab.net <> CollabNet | Distributed Development On Demand
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Dec 8 21:53:55 2005