Re: Why does ~DeferredReadManager read?

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.
Received on Mon Nov 03 2008 - 18:12:57 MST