Thanks for making this more clear. I was wrong to suggest pbuf_queue.
You really are creating a single logical data set, and the way that
pbuf_chain manages tot_len seems most relevant.
If you look in tcp_in.c, in tcp_receive, you will find a call to
pbuf_chain that seems analogous to yours. It is followed by a call to
pbuf_free, which undoes the ref increment in pbuf_chain. In fact, when
I scanned the code in core, I found that every pbuf_chain call was
followed immediately by a pbuf_free. I have to agree that this
situation does make it seem that perhaps the operations of the pbuf
chain and queue functions aren't as convenient to the caller as they
might be.
In defense of the way things are, however, the caller of pbuf_chain is
still in possession of both of the pbuf pointers upon return. It isn't
clear (to pbuf_chain) whether the caller will abandon the one that has
been attached to the chain or continue to use it. The pbuf_free call
after pbuf_chain makes this clear, though perhaps at the cost of
efficiency.
Tim Newsham wrote:
The pbuf_chain function that you are calling is appropriate if you are
trying to assemble a single packet from multiple pbufs. It is not
appropriate if you are trying to create a multi-packet queue. The
pbuf_queue function does that. Same goes for pbuf_dechain and pbuf_dequeue.
Somewhat inbetween in my situation. The pbuf is a chain of data
passed up from tcp (no longer packetized). I found out I was getting
two chains with refs (1,1) and (1,1). When I queued them together
it bumped the ref on the second resulting in (1,1,2,1). What
I ended up doing (hack) for the moment is bumping the ref on
all of the items in the chain after the head (ie 1,2 and 1,2)
before queueing them. After that I can dequeue them one at a time.
The purpose of this buffer was to queue up received data before
delivering it to the client. I think the code is still flawed
slightly in that if the client wants too much data, lwip will
run out of space before the request can be completed and I
will probably end up locking up the system.
Tim N.
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
|