Re: [lwip-users] pbuf proccessing in another thread

[ncoage]

> It makes sense, but it's not the way I would do it.  I would make the
> thread that writes to the queue responsible for not overflowing it.
> Have some state about the queue (e.g. read and write pointers) shared
> between the two threads so it knows how much space there is.  If it has

It's easy since I'm using FreeRTOS Queue.

> more data from TCP than it can fit in the queue, it just holds on to the
> TCP data until there is space.  It would do this by only calling

But I must do something with the data that cannot be put on queue. I should 
copy the data to a separate buffer or concatenate this pbuf with the pbuf chain 
(stored in the server state variable)?

> tcp_recved for data that it has put on the queue; this would keep the
> TCP receive window closed until it is ready for more data but not
> require a 200 byte TCP window which would be very bad for network
> performance.  You can use tcp_poll() to get a periodic callback to allow

The minimum interval between tcp_poll calls is 250ms, and I'm wondering if this 
is not too much.

> you to test the queue again and see if any of the data you delayed
> putting in the queue could now be written out (and of course call
> tcp_recved() for if so).
> 
> Kieran

Thanks for your advices.