OTBufferInfo, et. al.
OTBufferInfo, et. al.
- Subject: OTBufferInfo, et. al.
- From: "Thomas E. Knowlton, Jr." <email@hidden>
- Date: Fri, 23 Jan 2004 14:28:43 -0700
Hello, all. A couple of questions regarding no-copy receives in OT.
After doing a no-copy OTRcv, I've got a pointer to a (chain of)
OTBuffer.
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?
If it is the case that OTReadBuffer updates fBuffer as it chases links,
(2) does OTReadBuffer call OTReleaseBuffer on the previous value of
fBuffer? (If not, wouldn't there be a resource leak?)
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)? This may explain an
apparent (OT) resource leak in my application: I've been of the
impression that OTReleaseBuffer actually reclaims all of the buffers in
the chain, and so I've been calling OTReleaseBuffer on the head item
only, as demonstrated in the sample code on p.224.
Alternatively, it could be the case that OTReadBuffer updates fOffset
as an offset into the entire chain starting at fBuffer, and never
updates fBuffer. Then, OTReadBuffer would have to chase the links in
each call after the first buffer is exhausted, to locate the read
cursor. That would imply that code that uses that API could "seek" by
setting fOffset before doing the OTReadBuffer.
Finally, for a given OTBufferInfo, is the result of OTBufferDataSize
invariant? Or would I be able to use it as a convenient way to compute
how much unread data remains in a buffer chain?
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?
Thanks,
--Tk
[demime 0.98b removed an attachment of type image/tiff which had a name of pastedGraphic2.tiff]
[demime 0.98b removed an attachment of type image/tiff which had a name of pastedGraphic3.tiff]
[demime 0.98b removed an attachment of type image/tiff which had a name of pastedGraphic4.tiff]
[demime 0.98b removed an attachment of type image/tiff which had a name of pastedGraphic5.tiff]
_______________________________________________
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.