Ah, that's just a limit on write though. All writing needs to happen at the
first available byte so it is naturally constrained. The second block is
checked only so that if the first block is full a new block is *not* allocated
until it is needed. For this same reason it should never be the case that the
chain starting at the writer is longer than 2. Note that the reader(s) can be
much further back along the chain. The presumed logic for writing is to write
the first block, then check the MIOBuffer write_avail to set up for the next
write as that method will add a block if insufficient space is available in the
write chain. There's really no advantage to pre-allocating for write any
further than 1 block.
On Friday, May 27, 2016 11:08 AM, Craig Schomburg (craigs) <cra...@cisco.com>
wrote:
Alan,
Here is the limit I mentioned:
/**
Returns a pointer to the first writable block on the block chain.
Returns NULL if there are not currently any writable blocks on the
block list.
*/
IOBufferBlock *
first_write_block()
{
if (_writer) {
if (_writer->next && !_writer->write_avail())
return _writer->next;
ink_assert(!_writer->next || !_writer->next->read_avail());
return _writer;
} else
return NULL;
}
first_write_block will look at only the first 2 buffer blocks in the list when
the pointer to the first buffer block is requested. So if you had a chain of
more than 2 buffers in the list and the first 2 were full we do not continue to
iterate through the possible list.
