per-thread malloc pools are probably enough to solve this problem and are probably only a few dozen lines of code? i haven't written one so i could be wrong, but it sounds like it might be an acceptable fix to musl
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.
hi, i’m _reasonably_ familiar with libcs, specifically glibc and musl. even a cursory investigation would reveal how involved these things are. classic hn.
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
