Re: [lwip-users] about memory problem

[address@hidden]

Since lwIP is designed for embedded systems, this doesn't make much 
sense since you will have to provide the memory anyway, either for the 
heap (malloc) or in the memp pools. By using malloc the way you 
suggested you risk running out of structures. Of course with the heap 
approach you can use the (currently unused) memory in one pool for 
something else, but most embedded developers dislike this because it is  
unpredictable. Aside from that, pools are much faster than the heap.

If you still want to do it, the simplest way is to not include memp.c in 
your binary (don't link/compile it) and change memp.h to something like 
this:
#define memp_free(type, mem) free(mem)
#define memp_malloc(type) malloc(memp_sizes[type])

However, I doubt runtime-allocation of pools will be a) easy to achieve 
without increasing complexity of the memp code (which is currently quite 
small) and b) will ever make it into lwIP CVS code.

Simon


Rishi Khan wrote:
> Has anyone looked into setting up the memory pools such that if they  
> run out more can be allocated? The most straightforward way would be  
> to simply malloc each new memory type when the pool runs out and free  
> it when it is free. However, a more clever approach would be to make  
> a new pool. The problem I have is that I don't want to allocate a  
> bunch of space for TCP connections that don't exist but I don't want  
> an error if I want to open 30 TCP connections. The same goes for PBUF  
> objects. I would like to allocate 10 or so and add 10 at a time until  
> some limit (say 100). Has anyone looked into something like this for  
> lwip?
>
> Rishi
>
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>