On Sun, 2008-11-02 at 13:46 +1300, Amos Jeffries wrote:
> Robert Collins wrote:
> > On Sat, 2008-11-01 at 10:45 -0600, Alex Rousskov wrote:
> >> Moreover, if we must read until EOF before we close, then the cleanup
> >> code would have to be rewritten in many places, not just the deferred
> >> read-related ones!
> >
> > src/comm.cc line 353:
> > /**
> > * Empty the read buffers
> > *
> > * This is a magical routine that empties the read buffers.
> > * Under some platforms (Linux) if a buffer has data in it before
> > * you call close(), the socket will hang and take quite a while
> > * to timeout.
> > */
> > static void
> > comm_empty_os_read_buffers(int fd)
> > {
> > #ifdef _SQUID_LINUX_
> > /* prevent those nasty RST packets */
> > char buf[SQUID_TCP_SO_RCVBUF];
> >
> > if (fd_table[fd].flags.nonblocking == 1) {
> > while (FD_READ_METHOD(fd, buf, SQUID_TCP_SO_RCVBUF) > 0) {};
> > }
> > #endif
> > }
> >
>
> Aha, thanks Robert that was it exactly.
>
> Two seconds more thought and this API seems to be what the destructor
> should be doing instead of kicking off its own internal read.
But we are already doing the above for all sockets, including sockets
with deferred reads. If I am not misreading the code, it still looks
like we can just ignore deferred read handlers when their manager is
being destructed, right?
Thank you,
Alex.
