Jeff Trawick wrote:
Jacob Craig Lewallen wrote:
I assume that your app did
apr_socket_timeout_set(sock, 0)
to clear the timeout?
Actually I am passing -1, which does "clear" the timeouts. Unfortunately the socket is still non blocking. . . If you look in sockopt.c on line 133 you'll see a call to apr_is_option_set, checking for APR_SO_NONBLOCK. My problem is, this never gets set when it DOES make the socket non blocking in the first call to timeout_set and so the socket is never returned to blocking even if you do pass -1. In other words, on the first call on a blocking socket it'll check for NONBLOCK, fail, and set the socket to be non blocking, but never set the APR_SO_NONBLOCK flag to reflect this. Or am I just being dense?
No, you're not being dense.
To be honest, I thought your previous note was clear about the bug but then when I went to try it empirically I couldn't reproduce it. Then I wondered if you had passed the right value to apr_socket_timeout_set() :)
Looking at things again, perhaps before injesting enough caffeine, it looks like there are other bogosities w.r.t. timeouts that perhaps hid the bug from me for my particular testcase. I see various places where we think that sock->timeout != 0 means there is a timeout in place, when a check via apr_is_option_set(sock->netmask, APR_SO_TIMEOUT) is the proper thing to do.
I now see that your patch needs to be committed, but for the short term I'd like to explore some other bogosities.
Thanks for hanging in there!
