On 02/01/2012, at 1:18 PM, James Peach wrote:

> On 02/01/2012, at 11:30 AM, Brian Geffon wrote:
> 
>> I think you might want TSIOBufferBlockReadAvail and not 
>> TSIOBufferReaderAvail.
> 
> Hmm, so my code is assuming that all the data is in the first buffer block. 
> It sounds like that it not guaranteed and that I ought to be calling 
> TSIOBufferBlockNext() if the first buffer block doesn't have all the data.

After some more testing, I think that this is a bug. TSIOBufferReaderAvail() 
returns 43, but there are subsequently 0 bytes available. Iterating the buffer 
blocks as below confirms this. My understanding of TSIOBufferReaderAvail() and 
the assumption of other usages of it that I have seen is that the data in teh 
buffer blocks should all add up to the available count from the buffer reader. 
I haven't seen any indication that TSIOBufferReaderAvail() is advisory.

static size_t
count_bytes_available(
        TSIOBuffer          buffer,
        TSIOBufferReader    reader)
{
    TSIOBufferBlock block;
    size_t count = 0;

    block = TSIOBufferStart(buffer);
    while (block) {
        const char * ptr;
        int64_t nbytes = 0;

        ptr = TSIOBufferBlockReadStart(block, reader, &nbytes);
        if (ptr && nbytes) {
            count += nbytes;
        }

        block = TSIOBufferBlockNext(block);
    }

    return count;
}

> 
> thanks,
> James
> 
>> 
>> Brian
>> ________________________________________
>> From: James Peach [jamespe...@me.com]
>> Sent: Saturday, December 31, 2011 10:07 PM
>> To: dev@trafficserver.apache.org
>> Subject: inconsistent read IOBuffer results
>> 
>> Hi all,
>> 
>> In my proxy code, I have something that looks roughly like this:
>> 
>>       if (TSIOBufferReaderAvail(reader) >= 10) {
>>               blk = TSIOBufferStart(buffer);
>>               ptr = (const uint8_t *)TSIOBufferBlockReadStart(blk, reader, 
>> &nbytes);
>> 
>>               TSReleaseAssert(nbytes >= 10);
>>       }
>> 
>> Occasionally, the assertion will trigger; is that something that I should 
>> expect and handle?
>> 
>> cheers,
>> James
> 

Reply via email to