Simon, > My question is: has anyone ever bothered to somehow avoid using a > heap and using pools instead?
Can remember being a bit conservative about using mem_malloc for 24/7 use myself. Most literature about RT systems is quite biased againsed malloc for many good reasons. However you shouldn't be too frightened by mem_malloc fragmentation unless you have a malloc which performs very poor in this respect. We had this discussion before on this list and frankly I'm not a bit afraid using malloc for non/soft RT, 24/7 sytem stuff now. You'll certainly run into other troubles when trying to avoid it to great lengths. Let's quote (and learn from) McKusick and Karels (from the BSD kernel malloc paper): "A generalized memory allocator is needed to reduce the complexity of writing code inside the kernel. Rather than providing many semi-specialized ways of allocating memory, the kernel should provide a single general purpose allocator. With only a single interface, programmers do not need to figure out the most appropriate way to allocate memory. If a good general purpose allocator is available, it helps avoid the syndrome of creating yet another special purpose allocator." Search'n'replace "kernel" with "lwip" and you get my point. Too many hackers here, with too many good ideas for their own lwIP setup, I'm afraid. > I would favor solving this problem by 'fixing' savannah bug #3031 > submitted by Leon Woestenberg, which basically proposes getting rid > of PBUF_RAM and using pools instead. Different issue. #3031 is nice to have, and may solve some other odd corners. Doesn't solve fragmentation. I'm open for fragmentation test results and test cases for our mem_malloc() though... Christiaan Simons Hardware Designer Axon Digital Design http://www.axon.tv _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
