Re: Why does ~DeferredReadManager read?

Alex Rousskov wrote:
> 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?

I haven't checked the whole chain. All that matters is that its called
once before socket close. If you have found a second spot, great some
code reduction :)

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE5 or 3.0.STABLE10
   Current Beta Squid 3.1.0.1