lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Re: [lwip] Where to free the pbufs?


From: Adam Dunkels
Subject: [lwip-users] Re: [lwip] Where to free the pbufs?
Date: Thu, 09 Jan 2003 01:45:46 -0000

Hi Steve!

On Tuesday 18 December 2001 10.52, you wrote:
> I am getting confused about where pbufs should be freed up.
>
> I have written a simple tcp echo function which calls tcp_write without
> copy to reflect anything that comes in. After a while it all hangs up and I
> think the pbufs are
> messed up.

The problem here is that tcp_write() isn't designed to process pbufs, but 
arrays of data. tcp_write() does its own packagjng of the data into pbufs 
internally. It would be possible to add a function for sending pbufs with TCP 
directly, but I didn't think that applications would benifit much from such a 
function so I never implemented it. 

A workaround in this particular case would be to copy the data into a new 
buffer and send it with tcp_write(). When the tcp_sent() callback is called 
enough times to inform that the data has been acknowledged, the buffer can be 
dellocated.

> Have I missed something - is it OK to free pbufs twice?

Since the pbufs include a reference count, they can be freed numerous times. 
When the reference count is > 1, a deallocation doesn't really deallocate the 
buffer, it only decrements the reference count. 

TCP utilizes this when data is sent out. Since the data may have to be 
retransmitted, the reference count of the pbufs are increased before they are 
passed down to the IP layer. The IP layer free()s the pbufs after they have 
been handed over to the network interface code. If that code has to queue the 
pbufs before transmission, they should increase the reference count (using 
pbuf_ref()) first.

> _ we are using quite an old copy of the stack have there been recent
> changes in this area?

No.

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam
[This message was sent through the lwip discussion list.]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]