Paul TBBle Hampson wrote:
Or talloc, which lets you allocate hierarchially, so when you delete a request, all the stuff in it gets deallocated as well, without having to guess ahead of time how much space it's all gonna take.
I've been following Samba for a while. talloc is nice, but I think it's way overkill for what we need.
And it has destructors.
Which I don't think we need. For RADIUS, all memory allocation is either global, per-module instance, or tied to a REQUEST. The memory pools are probably best used for REQUESTs. My tests indicate that malloc/free overhead for a REQUEST with few VALUE_PAIRs can be up to 10% of CPU time. So fixing that would help performance, and would likely simplify the code. What's in a REQUEST? RADIUS_PACKETs, VALUE_PAIR's, and not much else. They don't need destructors on exit, so that overhead in a memory pool can be lost. We don't need thread locks on a REQUEST, as the server design guarantees that only one thread is accessing a REQUEST at a time. I think we can have simple 2k-page memory pools with only 100 to 200 lines of code. And, that means no external dependencies, either. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog