Re: seen_offset vs copy_offset

On Mon, 25 Dec 2000, Adrian Chadd wrote:

>
> Hi,
>
> Can I please get someone to sanity check this?
>
> I'm looking at seen_offset vs copy_offset in the store client code.
>
> As far as I can tell, seen_offset is used to limit calling
> the store client completion callback even if some data is
> ready to be returned.

I'll try to explain it.

The client side wants the storage manager to copy some data
into a buffer. The client says "I want you to start copying
at 'copy_offset' into the object data."

There are times when maybe the storage manager didn't have
all the data that the client wants. Partial HTTP headers
is the obvious example.

The 'seen_offset' variable is how the client side tells the
storage manager how much of the object it has "seen." The
client doesn't want to be called again until there is some
data that it hasn't yet seen.

If you flat out remove 'seen_offset' (and don't change anything
else) then you get recusion/loops because the client side
doesn't increase 'copy_offset' until it is done with the
data.

In the case of partial HTTP response headers, the client
side code wants to get all the headers in one chunk. If it
doesn't then it makes another storeClientCopy() request
with copy_offset still set to zero. If you take out seen_offset,
then the storage manager would immediately make the store client
callback again because it has some data starting at zero that
it can give to the client.

> client_side.c uses this in a coule of places - for example in
> clientCacheHit() - if size bytes have been read from
> http->out.offset but we're still waiting for the rest
> of the reply headers, we set seen_offset to http->out.offset + size.
> We still have the data, but it seems that this code throws
> the data away and re-reads it again ..

Yes, in this case the partial headers are "thrown out" and
copied again.

> Can someone familiar with the black magick in the storage manager
> please tell me whether (a) this is true, and (b) there is a real
> need to have this in the code, vs filling the remainder of
> the buffer (ie copy into buf + size, total byte length bufsize - size)..

Off the top of my head I don't know if your alternative would work.

Duane W.
Received on Sun Dec 31 2000 - 17:17:40 MST