fixing deferred reads

On Thu, 2008-09-25 at 11:32 -0600, Alex Rousskov wrote:
> On Thu, 2008-09-25 at 14:08 +0800, Adrian Chadd wrote:
> > 2008/9/25 Alex Rousskov <rousskov_at_measurement-factory.com>:
> >
> > > The DescriptorSet class has O(1) complexity for search, insertion,
> > > and deletion. It uses about 2*sizeof(int)*MaxFD bytes. Splay tree that
> > > used to store half-closed descriptors previously uses less RAM for small
> > > number of descriptors but has O(log n) complexity.
> > >
> > > The DescriptorSet code should probably get its own .h and .cc files,
> > > especially if it is going to be used by deferred reads.
> >
> > Could you do that sooner rather than later? I'd like to try using this
> > code for deferred reads and delay pools.
>
> Done. See src/DescriptorSet.{cc,h}

What a coincidence. I just got a deferred read assertion and was forced
to look at the related comm code. I think it needs changes similar to
what I just did to the half-closed code.

I can probably fix it myself, but it would help a lot if somebody could
document (briefly!) the overall purpose of deferred reads and the exact
purposes of these two nearly identical methods (one brief description
for each, please):

DeferredReadManager::kickReads(int const count)

and

DeferredReadManager::flushReads()

Finally, is there an implicit guarantee that the code scheduling a
deferred read has a close handler for the same descriptor? I think
deferred reading code assumes that because it does not notify the user
of descriptor closing.

Thank you,

Alex.

#3 0x08103854 in xassert (msg=0x823e2b7 "p != NULL",
    file=0x823d858 "comm.cc", line=1855) at debug.cc:574
#4 0x081b13c3 in comm_remove_close_handler (fd=43,
    handler=0x81b5048 <DeferredReadManager::CloseHandler(int, void*)>,
    data=0x13d66940) at comm.cc:1855
#5 0x081b50f6 in DeferredReadManager::popHead (deferredReads=@0xbfbfe8d0)
    at comm.cc:2672
#6 0x081b5246 in DeferredReadManager::flushReads (this=0x13821b48)
    at comm.cc:2706
#7 0x081b4f43 in ~DeferredReadManager (this=0x13821b48) at comm.cc:2640
#8 0x0815f47f in ~MemObject (this=0x13821ac8) at MemObject.cc:128
#9 0x08181808 in StoreEntry::destroyMemObject (this=0x9737098) at store.cc:381
#10 0x08181924 in destroyStoreEntry (data=0x973709c) at store.cc:394
#11 0x08183ddb in StoreEntry::release (this=0x9737098) at store.cc:1291
#12 0x08181da5 in StoreEntry::unlock (this=0x9737098) at store.cc:503
#13 0x0819483d in ~ServerStateData (this=0x13a51010, __vtt_parm=0x8226864)
    at Server.cc:69
#14 0x0811ba74 in ~FtpStateData (this=0x13a51010) at ftp.cc:515
#15 0x081ba05f in AsyncJob::callEnd (this=0x13a5511c) at ICAP/AsyncJob.cc:136
#16 0x081bab6f in JobDialer::dial (this=0x13d6319c, call=@0x13d63180)
    at ICAP/AsyncJob.cc:221
#17 0x08129ff0 in AsyncCallT<CommCbMemFunT<FtpStateData, CommCloseCbParams> >::fire (this=0x13d63180) at AsyncCall.h:127
#18 0x080cda3b in AsyncCall::make (this=0x13d63180) at AsyncCall.cc:34
#19 0x080ccf2e in AsyncCallQueue::fireNext (this=0x83cacd0)
    at AsyncCallQueue.cc:53
#20 0x080ccd92 in AsyncCallQueue::fire (this=0x83cacd0) at AsyncCallQueue.cc:39
#21 0x0810e2de in EventLoop::dispatchCalls (this=0xbfbfece0)
    at EventLoop.cc:154
#22 0x0810e1b8 in EventLoop::runOnce (this=0xbfbfece0) at EventLoop.cc:119
#23 0x0810e0b4 in EventLoop::run (this=0xbfbfece0) at EventLoop.cc:95
#24 0x0815a767 in main (argc=2, argv=0xbfbfed74) at main.cc:1328
Received on Thu Sep 25 2008 - 19:43:48 MDT