Go में Context नियंत्रण

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

Go developers `context` और goroutines का जिम्मेदारी से उपयोग कैसे करें, इस पर विचार करते हैं, विशेष रूप से cancellation, resource lifetimes, और libraries में hidden concurrency से बचने पर। कई लोग synchronous दिखने वाले APIs को पसंद करते हैं जहाँ काम concurrent चले या नहीं, यह caller तय करे, हालांकि internal goroutines और लंबे समय तक चलने वाले workers के वैध उपयोग भी स्वीकार किए जाते हैं। चर्चा `context` को cancellation और request-scoped data के मिश्रण के रूप में भी आलोचना करती है, इसकी Rust और C# के patterns से तुलना करती है, और structured concurrency तथा Go के “no async coloring” आदर्श की सीमाओं पर भी बात करती है।

लाइब्रेरीज़ और API डिज़ाइन में Goroutines

  • मज़बूत थीम: library APIs को synchronous जैसा दिखना चाहिए; यदि callers concurrency चाहते हैं, तो वे खुद goroutines spawn करके यह तय करें।
  • Internal goroutines तब स्वीकार्य हैं जब वे:
    • abstraction का स्पष्ट हिस्सा हों (जैसे crawler, parallel map, batching pub/sub, metrics flusher)।
    • bounded, अच्छी तरह documented, और tunable हों (limits, rate, batching, in‑flight caps)।
    • public function के return करने से पहले ठीक से cleaned up किए जाएँ (structured concurrency style, अक्सर errgroup या WaitGroup के जरिए)।
  • “लाइब्रेरीज़ में कभी goroutines शुरू न करें” वाले critics इसे बहुत rigid मानते हैं; कुछ workloads ऐसे होते हैं जहाँ library द्वारा scheduling संभालना अधिक सरल और सुरक्षित होता है।
  • background goroutines में panics एक चिंता हैं: callers उन्हें recover में wrap नहीं कर सकते जब तक कि goroutine boundary उन्हीं के control में न हो।

Context: उद्देश्य, पैटर्न, और समस्या वाले बिंदु

  • दो मुख्य भूमिकाएँ:
    • Cancellation / deadlines / “अब आप रोक सकते हैं”。
    • request-scoped data (logger, tracing, auth, आदि)।
  • बहुत से लोग “bag of stuff” पहलू को पसंद नहीं करते; यह समझना कठिन है कि किसी function को context की ज़रूरत क्यों है या उसमें क्या है।
  • दूसरे लोग explicit ctx parameters का बचाव करते हैं:
    • interruptibility और logging requirements को visible बनाते हैं।
    • implicit thread-local storage की तुलना में review और reason करना आसान होता है।
  • बहस में रही guidance:
    • सामान्य नियम: contexts store न करें; उन्हें stack में नीचे pass करें।
    • nuance: structs में यह ठीक है जो effectively parameters हों, और stdlib में backward compatibility के लिए (जैसे net/http), कभी-कभी NewRequestWithContext का उपयोग।
    • context.WithoutCancel को “values but not deadlines” स्टोर करने के लिए एक उपयोगी compromise माना जाता है।
  • घर्षण वाले बिंदु:
    • static रूप से यह जानने का कोई तरीका नहीं कि callees context का सम्मान करेंगे या नहीं।
    • “लगभग हर function” में ctx thread करने का दबाव, खासकर logging के लिए।

Context बनाम Function Coloring / Async Models

  • कुछ लोग ctx को एक हल्का “coloring” मानते हैं (context वाले और बिना context वाले functions), जो Go की “no async keyword” कहानी को आंशिक रूप से कमजोर करता है।
  • दूसरे तर्क देते हैं कि यह async/await की तुलना में बहुत कम constraining है:
    • आप हमेशा context.Background() उपयोग कर सकते हैं या उसे timeouts के साथ wrap कर सकते हैं।
    • यह अन्य भाषाओं में दिखने वाली कठोर sync/async separation नहीं बनाता।

Error Handling & Zero Values (Side Thread)

  • (T, error) pattern पर बहस:
    • एक पक्ष: zero/nil values को error set होने पर भी “useful” होना चाहिए।
    • दूसरा: अधिकांश वास्तविक APIs में zero values meaningless या dangerous होती हैं; sum types की कमी awkward conventions को मजबूर करती है।