On 07/25/2017 01:37 AM, Yann Ylavic wrote: > On Tue, Jul 25, 2017 at 1:19 AM, <[email protected]> wrote: >> >> New abort_socket_nonblocking() allows to reset connections when nonblocking >> is >> required and we can't do much about the connection anymore, nor want the >> system >> to linger on its own after close(). >> > [] >> >> +static void abort_socket_nonblocking(apr_socket_t *csd) >> +{ >> + apr_status_t rv; >> + apr_socket_timeout_set(csd, 0); >> +#if defined(SOL_SOCKET) && defined(SO_LINGER) >> + /* This socket is over now, and we don't want to block nor linger >> + * anymore, so reset it. A normal close could still linger in the >> + * system, while RST is fast, nonblocking, and what the peer will >> + * get if it sends us further data anyway. >> + */ >> + { >> + apr_os_sock_t osd = -1; >> + struct linger opt; >> + opt.l_onoff = 1; >> + opt.l_linger = 0; /* zero timeout is RST */ >> + apr_os_sock_get(&osd, csd); >> + setsockopt(osd, SOL_SOCKET, SO_LINGER, (void *)&opt, sizeof opt); >> + } >> +#endif >> + rv = apr_socket_close(csd); >> + if (rv != APR_SUCCESS) { >> + ap_log_error(APLOG_MARK, APLOG_ERR, rv, ap_server_conf, >> APLOGNO(00468) >> + "error closing socket"); >> + AP_DEBUG_ASSERT(0); >> + } >> +} > > This change may be disputable... > > I wanted to: > 1. avoid blocking in any case (we can't where this is called), > 2. avoid issueing a nonblocking "normal" close() which lets the system handle > the burden of possibly leaking descriptors (until its own linger is done).
What is the real use case for 2.? Regards Rüdiger
