Re: [lwip-users] Query amount of free buffers

[Marco Jakobs]

Am 20.03.2010 22:38, schrieb address@hidden:
> Based on the event-callbacks, you should be able to know when writing 
> will succeed or not. This has been done already for the socket API: 
> writing to a non-blocking sockets won't be executed unless there's 
> enough buffer space available. And you can use select to wait for more 
> buffer space to get available. Unfortunately, something like select is 
> not available for the netconn API, so you'd either have to implement 
> this on your own or convert your application to use sockets instead of 
> netconns.

This is not so easy as i'm using the LwIP access in different tasks from 
the LwIP task, and the socket API is not thread-safe. So the netconn API 
is the most convenient way (and also working really smooth).

> BTW: I'm not sure I completely understood your deadlock situation, so 
> maybe my suggestions are wrong. Did I understand you correctly that 
> the tasks using netconn have a higher priority than the tcpip-task and 
> other tasks in your system? If so, why are these tasks running without 
> interruption? Maybe they should just sleep for a while when a write 
> fails?

The problem is that i won't get a feedback if the write fails. It just 
blocks. What i would need is a timeout option like netconn_rcv has one 
... and if the write returns and a flag would show me that it is not 
written, i may put the task to sleep.

But in this case we *have* still all buffers full. My goal would be to 
prevent the buffers from getting full. If the "flow-away" got stuck due 
to a "partially dead" GPRS /UMTS link, i would like to get this 
information *before* all buffers are used and the write fails. Putting 
the task to sleep or not, in this state my control communication over 
the ethernet will also not work as there are no buffers left for my 
UDP-netconn_write's.

Marco