On Sat, 2008-11-01 at 15:34 +1300, Amos Jeffries wrote:
> >
> > Does anybody know why DeferredReadManager destructor forces deferred
> > reads to read by calling flushReads? Besides leading to bugs, it seems
> > kind of pointless to try to read if the object that guarded deferred
> > reads is being destructed anyway.
> >
> > Should DeferredReadManager destructor cancel all pending operations
> > instead?
>
> I can't find it anymore, but seem to recall some of the other old FD
> closing code had notes about linux nastiness extending TIME_WAIT for
> sockets with data queued even after frormaly closed. Maybe its related
> to that.
If that is the case, we have a problem because scheduling reads from a
sequence of destructor calls is not going to work reliably even if we
find and fix all the current bugs. A class destructor should only do
straightforward cleanup. It must not throw or call virtual functions.
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!
Thank you,
Alex.
Received on Sat Nov 01 2008 - 16:46:07 MDT
This archive was generated by hypermail 2.2.0 : Sun Nov 02 2008 - 12:00:02 MST