> 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. _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
