Show HN: ब्लॉकिंग सेलेक्ट्स के साथ Go चैनलों का एक शुद्ध C89 इम्प्लीमेंटेशन

मूल लेख ↗ Hacker News चर्चा ↗

C में Go-शैली के चैनल और ब्लॉकिंग सेलेक्ट्स लागू करने वाली एक नई ओपन-सोर्स लाइब्रेरी ने इस पर बहस छेड़ दी है कि इतने पुराने C मानक को लक्ष्य बनाना पोर्टेबिलिटी के लिए लाभ है या API गुणवत्ता को नुकसान पहुँचाने वाली अनावश्यक बाधा। टिप्पणीकार नामकरण नियमों, `bool` के उपयोग, select semantics, allocator hooks, और चैनल बंद होने पर time-of-check/time-of-use बग जैसी concurrency edge cases जैसे डिज़ाइन विवरणों में उतरते हैं, और इस परियोजना की तुलना libmill, libdill, तथा ZeroMQ जैसी विकल्पों से करते हैं। तकनीकी आलोचना के साथ-साथ कई प्रतिभागी सार्वजनिक code reviews में लहजे और शिष्टाचार पर भी विचार करते हैं, जो कठोर प्रतिक्रिया और स्वयंसेवी मेंटेनरों के लिए स्वागतपूर्ण वातावरण बनाए रखने के बीच तनाव को उजागर करता है.

समग्र प्रतिक्रिया

  • कई टिप्पणीकारों को C में Go-शैली के चैनलों का विचार साफ़ और उपयोगी लगता है, खासकर सीमित या एम्बेडेड वातावरणों के लिए।
  • कई लोग लेखक के प्रयास और पोर्टेबिलिटी पर दिए गए फ़ोकस की सराहना करते हैं, भले ही वे व्यक्तिगत रूप से C89 का उपयोग न करें।

C89 बनाम नए C मानक

  • एक पक्ष का तर्क है कि C89 पुराना है: C11/C17 (और कुछ हद तक C99) व्यापक रूप से उपलब्ध हैं, और केवल C89 की बाधाएँ API की स्पष्टता (जैसे bool की कमी) और कोड गुणवत्ता को घटाती हैं।
  • दूसरे लोग C89 का बचाव पुराने कंपाइलरों, एम्बेडेड टूलचेन, और TinyCC या अन्य सीमित वातावरणों में बने प्रोजेक्ट्स के लिए एक व्यावहारिक पोर्टेबिलिटी लक्ष्य के रूप में करते हैं।
  • कुछ लोग बताते हैं कि लाइब्रेरी वास्तव में सख्ती से C89 नहीं है ही (मिश्रित डिक्लेरेशन/स्टेटमेंट्स, POSIX threads, कुछ एक्सटेंशन्स), और तर्क देते हैं कि “शुद्ध C89” लेबल भ्रामक है; बाद में लेखक स्पष्ट करता है कि उनका मतलब “-std=c89 के साथ कंपाइल होता है” है, न कि सख्त औपचारिक शुद्धता।

API और डिज़ाइन पर प्रतिक्रिया

  • सुझावों में शामिल हैं:
    • जहाँ संभव हो, स्थिति-शैली रिटर्न्स के लिए bool-जैसा प्रकार इस्तेमाल करें।
    • _dispose की बजाय _create/_destroy नामकरण को प्राथमिकता दें।
    • _t प्रत्यय से बचें क्योंकि POSIX इसे आरक्षित करता है (अन्य लोग कहते हैं कि यह व्यवहार में गैर-मुद्दा है)।
    • कस्टम allocators, logging hooks, और debug flags की अनुमति दें।
    • एक file descriptor expose करें ताकि चैनल existing event loops (select/epoll/kqueue/io_uring) के साथ एकीकृत हो सकें।
  • कुछ लोग यह भी रेखांकित करते हैं कि ये “header-level” डिज़ाइन निर्णय हैं जिन्हें बाद में ABI तोड़े बिना बदलना कठिन होता है।

Concurrency semantics और footguns

  • while (!closed(chan)) { … } को लेकर चिंता: यह classic time-of-check/time-of-use bug है यदि closed() जाँच और ऑपरेशन के बीच चैनल बंद हो जाए।
  • Go से तुलना: उसका receive ऑपरेशन परमाणु रूप से value और “open/closed” स्थिति दोनों लौटाता है; अलग closed() probe की बजाय यही पैटर्न सुझाया जाता है।
  • इस बारे में प्रश्न उठे कि बंद करने पर buffered messages का क्या होता है और बंद चैनल पर भेजने का व्यवहार क्या है; टिप्पणीकार चाहते हैं कि यह स्पष्ट रूप से दस्तावेज़ित हो।

अन्य लाइब्रेरियों और मॉडलों से तुलना

  • संबंधित परियोजनाओं का उल्लेख हुआ: libmill/libdill (coroutines और IO multiplexing के साथ CSP), ZeroMQ inproc sockets, Plan 9 libthread, CSP, और actors।
  • यह स्पष्ट किया गया कि यह लाइब्रेरी OS threads का उपयोग करती है, user-level coroutines का नहीं, इसलिए इसे उन coroutine schedulers के साथ सुरक्षित रूप से नहीं मिलाया जा सकता जो non-blocking primitives की अपेक्षा करते हैं।

समुदाय और लहजा

  • समीक्षा के लहजे पर पर्याप्त meta-discussion हुई: कुछ लोगों को लगा कि शुरुआती आलोचनाएँ अत्यधिक कठोर थीं; दूसरों का कहना है कि तकनीकी प्रतिक्रिया मूल्यवान है, बशर्ते उसे अधिक सावधानी से प्रस्तुत किया जाए।