Re: OTBufferInfo, et. al.
Re: OTBufferInfo, et. al.
- Subject: Re: OTBufferInfo, et. al.
- From: Quinn <email@hidden>
- Date: Tue, 27 Jan 2004 13:31:54 +0000
At 14:28 -0700 23/1/04, Thomas E. Knowlton, Jr. wrote:
Then, suppose I call OTReadBuffer. Now, the documentation indicates
that OTReadBuffer will update fOffset as it consumes the data.
(1) Does that API also modify the OTBufferInfo's fBuffer, to point at
the next buffer in the chain as needed?
Yes.
If it is the case that OTReadBuffer updates fBuffer as it chases links,
(2) does OTReadBuffer call OTReleaseBuffer on the previous value of
fBuffer?
No.
(If not, wouldn't there be a resource leak?)
No. See below for a discussion of why.
If that's so, then
(3) is it the case that OTReleaseBuffer only reclaims the buffer it is
passed, and not any chained buffers (using fNext)?
OTReleaseBuffer will release the entire chain.
The basic idea behind a no-copy receive is as follows.
1. You get the buffer chain from OTRcv.
2. You must eventually free the buffer chain using OTReleaseBuffer.
3. You may use OTReadBuffer as a /helper/ to access the buffer, but
it's not required. If you do use OTReadBuffer, you initialise the
OTBufferInfo structure with the head of the buffer chain and then you
read away. However, none of this affects the original copy of the
buffer pointer that you got in part 1.
Finally, for a given OTBufferInfo, is the result of OTBufferDataSize
invariant?
I don't understand this question. OTBufferDataSize operates on a
buffer chain (OTBuffer *), not a buffer info (OTBufferInfo *).
For a given buffer chain, OTBufferDataSize is invariant. That is, it
starts at the head of chain and adds up the size of each entry.
Here's the code.
extern "C" size_t OTBufferDataSize(OTBuffer* buf)
{
size_t len = 0;
while ( buf != NULL )
{
if ( buf->fType == M_DATA )
len += buf->fLen;
buf = buf->fNext;
}
return len;
}
Is there someone monitoring this list who is sufficiently familiar with
the implementation to give me a better idea of the intent of these API?
Well, yes, although, due to an combination of over-zealous tidying up
of my hard disk and a weird corruption of the source code disk images
on the DTS file server, I had to dig up the traditional Mac OS OT
source from a CD
btw This response assumes you're developing for traditional Mac OS.
I believe that the Mac OS X OT compatibility library will only ever
return single entry buffer chains. No-copy receives make no sense on
Mac OS X anyway; they're actually less efficient that copying
receives.
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.