तो आप अपनी C लाइब्रेरी में कस्टम allocator support चाहते हैं
C libraries के लिए custom memory allocators बेहतर performance, flexibility, और tooling integration का वादा करते हैं, लेकिन उनके design में safety और practicality से जुड़े कठिन सवाल उठते हैं। टिप्पणीकार उन APIs पर बहस करते हैं जो callers से object sizes, alignment, और context pointers पास करने की माँग करती हैं—कुछ का कहना है कि इससे allocation तेज़ हो सकती है और debugging में मदद मिलती है, जबकि दूसरे नोट करते हैं कि वास्तविक दुनिया का C code अक्सर इन विवरणों को भरोसेमंद तरीके से track नहीं करता और अधिक fragile हो सकता है। यह thread minimalist “single allocator function” designs की तुलना अधिक स्पष्ट लेकिन verbose interfaces से भी करती है, और दिखाती है कि ये विकल्प multithreaded scaling, ASAN/valgrind जैसे tools के integration, और arenas तथा stack allocators जैसे patterns के समर्थन को कैसे प्रभावित करते हैं।
Allocator APIs की सुरक्षा और शुद्धता
- कई टिप्पणीकारों का तर्क है कि free/realloc पर size देना कई bugs को रोक सकता था, लेकिन दूसरे कहते हैं कि caller द्वारा दिए गए sizes पर भरोसा करना खतरनाक है और उन्हें फिर भी जाँचना चाहिए।
- कुछ लोग बताते हैं कि कई allocators metadata या arenas के जरिए sizes पहले से ही जानते हैं, इसलिए अतिरिक्त size arguments अक्सर सिर्फ काम दोहराते हैं, जब तक उन्हें hints की तरह न माना जाए।
- लेख के इस दावे पर विरोध भी है कि callers के पास “हमेशा” original size होता है; लोग ऐसे यथार्थवादी counterexamples देते हैं जहाँ ऐसा नहीं होता।
Size और alignment information पास करना
- free पर size पास करने के समर्थकों का कहना है कि इससे costly arena/bucket lookups और metadata access से बचा जा सकता है।
- दूसरे बताते हैं कि modern allocators आमतौर पर बिना walks के size को सस्ते में recover कर सकते हैं।
- कई टिप्पणियाँ तर्क देती हैं कि extended alignment interface का हिस्सा होना चाहिए; कुछ लोग हर call के लिए explicit alignment parameter चाहते हैं, जबकि कुछ context या अलग aligned-alloc APIs पर निर्भर करते हैं।
- इस पर बहस है कि alignment अनिवार्य है (सही free के लिए) या “सिर्फ एक hint” हो सकता है।
Single-function बनाम multi-function allocator interfaces
- एक पक्ष को एक ही
allocate(ptr, size, ...)style API पसंद है, जो argument combinations के जरिए malloc/realloc/free को encode करती है; वे simplicity और छोटे footprint (जैसे Lua-like designs) का हवाला देते हैं। - आलोचक कहते हैं कि operations को combine करने से reasoning जटिल होती है, ambiguous edge cases (
alloc(NULL, 0)) आते हैं, और review तथा tooling मुश्किल हो जाते हैं; वे अलग-अलग alloc/free/realloc को प्राथमिकता देते हैं।
Caller-managed बनाम library-managed allocation
- कुछ लोग ऐसे APIs का समर्थन करते हैं जहाँ caller खुद allocate करता है, संभवतः two-pass patterns (size-compute then write), resumable operations, या लेख में बताए गए “pass an allocator callback” के जरिए।
- दूसरे जवाब देते हैं कि यह केवल सरल मामलों (जैसे
snprintf-like) में काम करता है, जबकि जटिल libraries (XML DOMs, आदि) अनिवार्य रूप से internally allocate करती हैं और pluggable allocators से लाभ उठाती हैं।
Threading और performance
- चर्चा में बताया गया है कि global-state allocators scale खराब करते हैं; thread-local caches के साथ cross-thread frees के लिए mechanisms (queues, CAS, per-sizeclass locks) सामान्य mitigations हैं।
- इस बात में रुचि है कि multicore scaling अच्छी रखते हुए ऐसी schemes को कितनी सरलता से implement किया जा सकता है।
वास्तविक दुनिया की C सीमाएँ और zero-size allocations
- कई टिप्पणियाँ इस बात पर जोर देती हैं कि बहुत-से मौजूदा C codebases sizes को सख्ती से track नहीं करते, खासकर null-terminated strings और flexible arrays के साथ।
malloc(0)के अर्थ और उपयोगिता, तथा 0 या -1 जैसे special numeric values के साथ in-band signaling पर बहस है।
Tooling और integration
- कुछ लोग जोर देते हैं कि allocator APIs को ASan और Valgrind जैसे tools के साथ integrate होना चाहिए; annotations को सीधा लेकिन आवश्यक माना जाता है।