On 12/18/2008 02:38 PM, Jess Holle wrote: > P.S. Matt Stevenson's fix/workaround seems to have done the trick quite > nicely. I tend to agree with the comments on the httpd group, however > -- one shouldn't have to do such things in code calling > apr_socket_connect(). Rather apr_socket_connect() should just do this > if necessary to ensure connection timeouts work. > > Thoughts?
I think the different behaviour origins from the way how apr_socket_timeout_set work on Unix and Windows. On Unix apr_socket_timeout_set makes the socket non blocking and on all further operations apr_wait_for_io_or_timeout is called to implement the timeout of the operation. On Windows the socket is kept in blocking mode in all cases except for timeout == 0, where it is placed in non blocking mode, and the socket timeout is done via SOL_SOCKET, SO_RCVTIMEO / SO_SNDTIMEO. As I am no Windows expert I cannot tell you if this approach is correct. Being a non Windows guy I currently see two approaches to solve this: 1. Adjust apr_socket_timeout_set on Windows in a way that it works similar to the one on Unix, which means that the socket is set to non blocking mode for timeouts >= 0. 2. Adjust apr_socket_connect on Windows such that it puts the socket in non blocking mode if timeout > 0 and reverts this in the end in order to have the socket in the same mode as before. I do not know if switching between blocking and non blocking mode on Windows changes the effect of the previously set SOL_SOCKET, SO_RCVTIMEO / SO_SNDTIMEO, such that these settings need to be repeated afterwards. So comments from Windows guys please. Regards Rüdiger
