Re: OTBufferInfo, et. al.
Re: OTBufferInfo, et. al.
- Subject: Re: OTBufferInfo, et. al.
- From: "Thomas E. Knowlton, Jr." <email@hidden>
- Date: Fri, 27 Feb 2004 09:53:08 -0700
Sorry for taking so long to get back to this... I actually missed
Quinn's reply when it came to the list a month ago...
Subject: Re: OTBufferInfo, et. al.
To: email@hidden
From: Quinn <email@hidden>
Date: Tue, 27 Jan 2004 13:31:54 +0000
>
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.
Here's what I was doing wrong: I've been allocating an OTBufferInfo,
and then passing the address of the fBuffer member to OTRcv. I think I
got this idea for no-copy receives from NWOT. As you can see, if the
fBuffer member of OTBufferInfo is your only record of the buffer chain
you get from OTRcv, you're bound to leak if you use OTReadBuffer.
In fact, I see the sample code on pp. 222-3 of NWOT exhibits exactly
the kind of leak I was conjecturing in my original post. Because it
doesn't cache the original OTBuffer* head of the chain, that code
"forgets" the original fBuffer value that OTRcv put into the
locally-allocated OTBufferInfo, and if OTReadBuffer ever returns true,
it will have adjusted the fBuffer member to nil, so that the code in
that example will in fact never release any buffers back to OT.
I hope you'll see this as a plea for improved documentation, not
sharpshooting. As far as that goes, I've been developing on Mac OS X
longer than I have been on Mac OS 9, and the quality of the API
documentation for X is greatly improved over what it (apparently) had
been before.
>
> 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 *).
I had the mistaken thought that OTReadBuffer was being more intimate
with the OTBuffer chain than it really is, to the point of actually
releasing each part of the chain as it is consumed.
>
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.
Thanks for saying so. I wouldn't have guessed this was the case; I seem
to remember quite the furor some years ago, over no-copy receives in
the BSD TCP/IP stack. Of course, that would have been kernel support of
Berkeley sockets, not XTI.
--
Tommy
>
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.