This will be useful with any data stream where data is considered to be a stream of bytes, as opposed to datagrams. E.g. TCP sockets. TCP retransmit queue management. UNIX sockets. Pipes.
> On Mar 2, 2016, at 11:29 AM, marko kiiskila <[email protected]> wrote: > > Freeing a single mbuf from the head of the chain is very common. > We should keep the API for that. > >> On Mar 1, 2016, at 9:58 PM, [email protected] wrote: >> >> I think having a single Api mbuf_free_chain is good. How many times have >> I forgot to free the chain in the past :(. >> >> The only caveat is that the user who knowingly wants to free a single mbuf >> at the head of a chain (for example freeing the header that they know they >> added) would need to unlink it first. To me that seems safer anyway since >> the programmer would need a pointer to the remainder of the chain >> regardless. >> >> >> >> On 3/1/16, 9:32 PM, "will sanfilippo" <[email protected]> wrote: >> >>> Hello: >>> >>> The os mbuf api has the following functions: os_mbuf_free() and >>> os_mbuf_free_chain(). Both of these are currently exposed in os_mbuf.h. >>> >>> I am thinking that os_mbuf_free should not be exposed; we should only >>> expose os_mbuf_free_chain. I would always want the developer to call a >>> function to free any mbufs chained to the mbuf being freed. >>> >>> Well, actually, I would prefer os_mbuf_free() to be exposed and have that >>> free the entire chain, but that would require chainging more codeŠ >>> >>> Yes, I know, trivial, but it is fresh in my mind :-) >>> >>> >>> >>> >> >
