On Mon, Aug 13, 2012 at 9:31 AM, Plüm, Rüdiger, Vodafone Group <ruediger.pl...@vodafone.com> wrote: > > >> -----Original Message----- >> From: Joe Orton [mailto:jor...@redhat.com] >> Sent: Montag, 13. August 2012 14:32 >> To: dev@httpd.apache.org >> Subject: core filters vs non-blocking socket (was Re: Fix for Windows >> bug#52476) >> >> On Fri, Aug 10, 2012 at 01:31:07PM -0400, Jeff Trawick wrote: >> > We picked up that apr_socket_opt_set() from the async-dev branch with >> > r327872, though the timeout calls in there were changed subsequently. >> > I wonder if that call is stray and it doesn't get along with the >> > timeout handling on Windows because of the SO_RCVTIMEO/SO_SENDTIMEO >> > use on Windows, in lieu of non-blocking socket + poll like on Unix. >> > >> > At the time it was added, the new code was >> > >> > apr_socket_timeout_set(client_socket, 0) >> > apr_socket_opt_set(client_socket, APR_SO_NONBLOCK, 1) >> > >> > (redundant unless there was some APR glitch at the time) >> >> Hmmmm, is this right? >> >> For event, the listening socket, and hence the accepted socket, is >> always set to non-blocking in the MPM. >> >> For non-event on Unix, the listening socket, and hence the accepted >> socket, is set to non-blocking IFF there are multiple listeners. >> >> So that line is not redundant in the non-event, single listener >> configuration on Unix... no? > > Don't we switch to non-blocking in apr_socket_timeout_set if we set the > timeout to 0?
yes apr_status_t apr_socket_timeout_set(apr_socket_t *sock, apr_interval_time_t t) { apr_status_t stat; /* If our new timeout is non-negative and our old timeout was * negative, then we need to ensure that we are non-blocking. * Conversely, if our new timeout is negative and we had * non-negative timeout, we must make sure our socket is blocking. * We want to avoid calling fcntl more than necessary on the * socket. */ if (t >= 0 && sock->timeout < 0) { if (apr_is_option_set(sock, APR_SO_NONBLOCK) != 1) { if ((stat = sononblock(sock->socketdes)) != APR_SUCCESS) { return stat; } apr_set_option(sock, APR_SO_NONBLOCK, 1); } } else if (t < 0 && sock->timeout >= 0) { if (apr_is_option_set(sock, APR_SO_NONBLOCK) != 0) { if ((stat = soblock(sock->socketdes)) != APR_SUCCESS) { return stat; } apr_set_option(sock, APR_SO_NONBLOCK, 0); } } ... > And if we do a read with a timeout don't we do a poll with a timeout where it > does not > matter whether the socket is blocking or non blocking? from a high-level, yes; but there is some logic in APR to guess when data is already available to read, and that requires that the socket is non-blocking in case the guess is incorrect (that logic is associated with the APR_INCOMPLETE_READ flag) > > Or did I get confused now completely? no > > Regards > > Rüdiger > -- Born in Roswell... married an alien... http://emptyhammock.com/