httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject Re: [PATCH] Big fixes to main loop, lingering_close
Date Sun, 16 Feb 1997 23:47:37 GMT
In message <Pine.LNX.3.95dg2.970215120241.23171C-100000@twinlark.arctic.org>,
Dean Gaudet writes:
>Just a side note about this code from l_c:
>
>#ifdef SELECT_NEEDS_CAST
>        select_rv = select(lsd+1, (int*)&fds_read, NULL, (int*)&fds_err,
>&tv);
>#else
>        select_rv = select(lsd+1, &fds_read, NULL, &fds_err, &tv);
>#endif
>    } while ((select_rv > 0) &&           /* Something to see on socket */
>             !FD_ISSET(lsd, &fds_err) &&   /* that isn't an error condition
*/
>             FD_ISSET(lsd, &fds_read) &&   /* and is worth trying to read
*/
>             ((read_rv = read(lsd, dummybuf, sizeof dummybuf)) > 0));
>
>On Linux, a select() on an fd which has "EOF in the queue" will return
>the fd bit in both the read and exception sets (i.e. there's still data
>to be read, but the Unix knows for certain that the other end has gone
>away on pipes or sockets).  I haven't seen any other Unix do this --
>but I did run into it in my mud code when using pipe()s.
>
>At this point the code would proceed with the close().  Since the kernel
>has already received the data, everything might just work "correctly"
>without us having to even read() it.

Yes, that is intentional -- we are waiting for any indication that the
client has "woken up" to the socket closing, whether that indication be
a FIN or a RST or just dropping off the net.  There is always a possibility
that the change is misdiagnosed, but since we are only doing this to
ensure delivery under normal conditions, we don't want to take the risk
of missing some obscure variation of a reset return.

....Roy

Mime
View raw message