[Top][All Lists]

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

Re: [lwip-users] about memory problem

From: address@hidden
Subject: Re: [lwip-users] about memory problem
Date: Thu, 17 Jul 2008 18:48:30 +0200
User-agent: Thunderbird (Macintosh/20080421)

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.


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?


lwip-users mailing list

reply via email to

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