Rusty's Bleeding Edge Page

Brian Aker made reference to talloc in his blog, which I've been thinking about a little. He notes (as I brushed over in my talk) that writing your own pool-based memory allocator is a well-worn sport: I knew Apache had one, and SAMBA had one (pre-talloc), but I wasn't aware of GTK's or MySQL's.

Now, there are three answers here to "why do people keep writing these things?". One reason is in one of my favourite Tridge quotes "You never need an excuse to rewrite something". (Note: IMHO Tridge is being generous. Tridge doesn't need an excuse. You and I, however, do).

Secondly, are several real improvements over straight pool allocators, especially avoiding the distinction between pools and allocations. Talloc heirarchies naturally reflect the lifetime relationships of the the data. As the code notes, Tridge stole this idea from halloc.

Finally, there is the reason I use and am excited about talloc, and the reason I thought it was the most important thing to talk about at LCA. This is why:

rusty@chopin:~/devel/cvs/talloc$ wc -l talloc.[ch]
 1208 talloc.c
  142 talloc.h
 1350 total

That's 1350 lines of code to drop into your project, not part of some toolkit you need to swallow whole. And that's way sweet.

[/tech] permanent link