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.
