5 ms·
Next question: why are there two calls to `malloc()`, one for the Pool structure and one for the Chunks? It is trivial to co-allocate them which removes the ri
by unwind 2y ago
Next question: why are there two calls to `malloc()`, one for the Pool structure and one for the Chunks?
It is trivial to co-allocate them which removes the risk of memory fragmentation and is just generally a good idea if you're chasing performance.
The answer might be "for clarity/simplicity" which I guess is fine in an informative article, but it could at least be highlighted in the text which I didn't see.
- 8dcc 2y agoI will also take note of this, you are right.
- jdnxbdn 2y agoIt is certainly not trivial and would add little to the topic
- kevin_thibedeau 2y agoHe's targeting ANSI C, C89. Flexible array members are not supported officially until C99. 26 years later, it's time to stop clinging to outdated standards and crusty tooling. Even Linux had to read the room and adopt C11. A C11 implementation could go one step further and use _Alignas(max_align_t) to keep the pool array aligned with no manual effort. The double allocation does this implicitly.
- liontwist 2y agoThe pool needs to align every allocation anyway.
- listeria 2y agoon the topic of alignment, the library (libpool) fails to align chunk_sz to allow storing a pointer when in the free_chunk list. This issue is sidestepped in TFA by using a union, which ensures appropiate alignment for all it's members, but in the library there's nothing which prevents me from asking for a chunk size of, say, 9 bytes, which would store pointers at misaligned addresses when creating the free-list.