> probably only a few dozen lines of code

Classic HN.

i'm guessing you haven't done it either, so you don't have any basis for guessing whether that's an underestimate or an overestimate

'classic hn' in the negative sense is a one-line dismissal containing no reasoning or information. do better

hi, i’m _reasonably_ familiar with libcs, specifically glibc and musl. even a cursory investigation would reveal how involved these things are. classic hn.

do better.

you can of course make malloc arbitrarily complex, and a simple malloc will not be very efficient, but musl's entire malloc/free implementation is only 600 lines of c (`cloc musl-1.1.24/src/malloc`) and even a fair bit of that is no longer actually used (`#if 1 ... #else ... #endif`)

so i don't think a cursory investigation supports your vague innuendo, which seems to be implying that adding thread-local allocation pools to musl would require enormously more than 'a few dozen lines of code', as i said. the entire allocator is 50 dozen lines

the code isn't 'involved'; it's nice and straightforward, except for a clever algorithm or two from hacker's delight. what's involved is debugging it when you break it

Most Good Things are a few dozen lines of code, don't let the Scrum Master fool you.

It's not a few dozen lines of code because of, among other things, the case in which one thread allocates a lot of memory that is then sent to another thread to be freed. This actually happens more frequently than you'd think, because of producer/consumer patterns. In that case stop-the-world synchronization must happen in order to re-balance the pools in order to avoid what are essentially memory leaks. This is complex and is actually fairly similar to garbage collection.

aha, thanks. it's true that i was thinking that just adding it to the receiver thread's pool would be sufficient