आज मैंने आपके लिए तथाकथित क्लोजर या क्लोजर के कार्यान्वयन के लिए एक संक्षिप्त लेख का अनुवाद करने का निर्णय लिया। इसके अलावा, आप जानेंगे कि विभिन्न मामलों में पॉइंटर / लिंक या मूल्य का उपयोग करने के लिए गो स्वचालित रूप से कैसे निर्धारित करने का प्रयास करता है। इन बातों को समझने से गलतियों से बचना होगा। और यह सिर्फ इतना है कि ये सभी इंसाइड दिलचस्प हैं, मुझे लगता है!

और मैं आपको 7 अक्टूबर को मॉस्को में आयोजित होने वाले गोलंग कॉन्फ 2019 में आमंत्रित करना चाहूंगा । मैं सम्मेलन की कार्यक्रम समिति का सदस्य हूं, और मेरे सहयोगियों और मैंने कई समान रूप से कट्टर और बहुत, बहुत दिलचस्प रिपोर्ट चुनी हैं। मैं क्या प्यार करता हूँ!

कटौती के तहत, मैं लेखक को शब्द देता हूं।

गो विकी पर एक पेज है जिसका शीर्षक है फ्रिक्वेंट मिस्टेक्स । उत्सुकता से, केवल एक उदाहरण है: गोरोइंट्स के साथ लूप चर का दुरुपयोग:

for _, val := range values { go func() { fmt.Println(val) }() } 

यह कोड मानों के मान (मान) बार के अंतिम मान से आउटपुट करेगा। कोड को ठीक करना बहुत सरल है:

 // assume the type of each value is string for _, val := range values { go func(val string) { fmt.Println(val) }(val) } 

यह उदाहरण समस्या को समझने के लिए पर्याप्त है और फिर कभी गलती नहीं करता है। लेकिन यदि आप कार्यान्वयन विवरण जानने में रुचि रखते हैं, तो यह लेख आपको समस्या और समाधान दोनों की गहरी समझ देगा।

बुनियादी बातें: मूल्य से गुजरना और संदर्भ से गुजरना

गो में, वस्तुओं को मूल्य से और संदर्भ द्वारा [1] पास करने में अंतर होता है। उदाहरण 1 [2] से शुरू करते हैं:

 func foobyval(n int) { fmt.Println(n) } func main() { for i := 0; i < 5; i++ { go foobyval(i) } time.Sleep(100 * time.Millisecond) } 

किसी को, सबसे अधिक संभावना है, इसमें कोई संदेह नहीं है कि परिणाम 0 से 4 तक के मूल्यों को प्रदर्शित करेगा। संभवतः किसी प्रकार के यादृच्छिक क्रम में।

आइए उदाहरण 2 देखें ।

 func foobyref(n *int) { fmt.Println(*n) } func main() { for i := 0; i < 5; i++ { go foobyref(&i) } time.Sleep(100 * time.Millisecond) } 

परिणामस्वरूप, निम्नलिखित प्रदर्शित किया जाएगा:

5
5
5
5
5

यह समझना कि परिणाम सिर्फ इतना क्यों है जो हमें समस्या के सार की समझ का 80% पहले ही दे देगा। इसलिए, आइए कारणों को खोजने के लिए कुछ समय लें।

और इसका उत्तर वहीं है जो गो भाषा विनिर्देश में है । विनिर्देश पढ़ता है:

प्रारंभिक विवरण में घोषित चर प्रत्येक लूप में पुन: उपयोग किए जाते हैं।

इसका मतलब यह है कि जब प्रोग्राम चल रहा है, तो चर i के लिए केवल एक ऑब्जेक्ट या मेमोरी का टुकड़ा है, न कि प्रत्येक चक्र के लिए एक नया बनाया गया है। यह वस्तु प्रत्येक पुनरावृत्ति पर एक नया मान लेती है।

आइए उदाहरण 1 में लूप के लिए उत्पन्न मशीन कोड [3] में अंतर देखें और 2 उदाहरण 1 से शुरू करें।

 0x0026 00038 (go-func-byval.go:14) MOVL $8, (SP) 0x002d 00045 (go-func-byval.go:14) LEAQ "".foobyval·f(SB), CX 0x0034 00052 (go-func-byval.go:14) MOVQ CX, 8(SP) 0x0039 00057 (go-func-byval.go:14) MOVQ AX, 16(SP) 0x003e 00062 (go-func-byval.go:14) CALL runtime.newproc(SB) 0x0043 00067 (go-func-byval.go:13) MOVQ "".i+24(SP), AX 0x0048 00072 (go-func-byval.go:13) INCQ AX 0x004b 00075 (go-func-byval.go:13) CMPQ AX, $5 0x004f 00079 (go-func-byval.go:13) JLT 33 

Go स्टेटमेंट runtime.newproc फ़ंक्शन के लिए कॉल बन जाता है। इस प्रक्रिया के यांत्रिकी बहुत दिलचस्प हैं, लेकिन हमें अगले लेख के लिए छोड़ दें। अब हम अधिक रुचि रखते हैं कि चर i के साथ क्या होता है। इसे AX रजिस्टर में संग्रहित किया जाता है, जिसे तब स्टैक के माध्यम से फोब्यवल फंक्शन [4] में इसके तर्क के रूप में मान दिया जाता है। इस मामले में "मूल्य से" स्टैक पर AX रजिस्टर के मूल्य की नकल करने जैसा लगता है। और भविष्य में एएक्स को बदलने से यह प्रभावित नहीं होता है कि फोबाइवल फ़ंक्शन को क्या पारित किया गया है।

और यहाँ उदाहरण 2 कैसा दिखता है:

 0x0040 00064 (go-func-byref.go:14) LEAQ "".foobyref·f(SB), CX 0x0047 00071 (go-func-byref.go:14) MOVQ CX, 8(SP) 0x004c 00076 (go-func-byref.go:14) MOVQ AX, 16(SP) 0x0051 00081 (go-func-byref.go:14) CALL runtime.newproc(SB) 0x0056 00086 (go-func-byref.go:13) MOVQ "".&i+24(SP), AX 0x005b 00091 (go-func-byref.go:13) INCQ (AX) 0x005e 00094 (go-func-byref.go:13) CMPQ (AX), $5 0x0062 00098 (go-func-byref.go:13) JLT 57 

कोड बहुत समान है - केवल एक के साथ, लेकिन बहुत महत्वपूर्ण, अंतर। अब AX में इसका पता i है, न कि इसका मान। यह भी ध्यान दें कि लूप के लिए वेतन वृद्धि और तुलना (AX) पर की जाती है, AX पर नहीं। और फिर, जब हम एक्सएक्स को स्टैक पर रखते हैं, हम, यह निकलता है, पता I को फ़ंक्शन में पास करें। बदलाव (AX) को गोरोइन में भी इस तरह से देखा जाएगा।

कोई आश्चर्य नहीं। अंत में, हम एक पॉइंटर को फोबायरेफ़र फ़ंक्शन के एक नंबर पर पास करते हैं।
ऑपरेशन के दौरान, चक्र तेजी से समाप्त हो जाता है, जिससे किसी भी तरह के निर्मित गोरोनाइट काम करने लगते हैं। जब वे काम करना शुरू करते हैं, तो उनके पास एक ही चर i के लिए एक सूचक होगा, और एक प्रति के लिए नहीं। और इस समय i का क्या मूल्य है? मान 5. वह बहुत जिस पर चक्र बंद हो गया। और यही कारण है कि सभी गोरआउट 5 प्राप्त करते हैं।

एक सूचक के साथ एक मूल्य वी.एस. तरीकों के साथ तरीके

गोरोनाइट्स बनाते समय इसी तरह का व्यवहार देखा जा सकता है जो किसी भी तरीके को लागू करता है। यह उसी विकी पृष्ठ द्वारा इंगित किया गया है। उदाहरण 3 देखें :

 type MyInt int func (mi MyInt) Show() { fmt.Println(mi) } func main() { ms := []MyInt{50, 60, 70, 80, 90} for _, m := range ms { go m.Show() } time.Sleep(100 * time.Millisecond) } 

यह उदाहरण एमएस सरणी के तत्वों को प्रदर्शित करता है। यादृच्छिक क्रम में, जैसा कि हमें उम्मीद थी। एक समान उदाहरण 4 शो विधि के लिए एक सूचक विधि का उपयोग करता है:

 type MyInt int func (mi *MyInt) Show() { fmt.Println(*mi) } func main() { ms := []MyInt{50, 60, 70, 80, 90} for _, m := range ms { go m.Show() } time.Sleep(100 * time.Millisecond) } 

यह अनुमान लगाने की कोशिश करें कि निष्कर्ष क्या होगा: 90, पांच बार मुद्रित। इसका कारण सरल उदाहरण में समान है। यहां सूचक विधियों का उपयोग करते समय गो में सिंटैक्टिक चीनी के कारण समस्या कम ध्यान देने योग्य है। यदि उदाहरणों में, उदाहरण 1 से उदाहरण 2 तक स्विच करते समय, हमने i और i में बदल दिया, तो कॉल समान दिखता है! m.Show () दोनों उदाहरणों में, और व्यवहार अलग है।

दो गो सुविधाओं का एक बहुत खुश संयोजन नहीं है, यह मुझे लगता है। कॉल के स्थान पर कुछ भी संदर्भ द्वारा प्रसारण को इंगित नहीं करता है। और आपको शो विधि के कार्यान्वयन को देखने की आवश्यकता होगी कि यह देखने के लिए कि कॉल कैसे होगा (और विधि, निश्चित रूप से, पूरी तरह से अलग फ़ाइल या पैकेज में हो सकती है)।

ज्यादातर मामलों में, यह सुविधा उपयोगी है। हम क्लीनर कोड लिखते हैं। लेकिन यहां, संदर्भ से गुजरने से अप्रत्याशित प्रभाव पड़ता है।

शॉर्ट सर्किट

अंत में हम क्लोजर पर आते हैं। आइए उदाहरण 5 पर देखें :

 func foobyval(n int) { fmt.Println(n) } func main() { for i := 0; i < 5; i++ { go func() { foobyval(i) }() } time.Sleep(100 * time.Millisecond) } 

वह निम्नलिखित प्रिंट करेगा:

5
5
5
5
5

और यह इस तथ्य के बावजूद है कि मुझे क्लोजर में फोबॉयवल के लिए मूल्य से पारित किया गया है। उदाहरण 1 के समान। लेकिन क्यों? आइए कोडांतरक लूप दृश्य को देखें:

 0x0040 00064 (go-closure.go:14) LEAQ "".main.func1·f(SB), CX 0x0047 00071 (go-closure.go:14) MOVQ CX, 8(SP) 0x004c 00076 (go-closure.go:14) MOVQ AX, 16(SP) 0x0051 00081 (go-closure.go:14) CALL runtime.newproc(SB) 0x0056 00086 (go-closure.go:13) MOVQ "".&i+24(SP), AX 0x005b 00091 (go-closure.go:13) INCQ (AX) 0x005e 00094 (go-closure.go:13) CMPQ (AX), $5 0x0062 00098 (go-closure.go:13) JLT 57 

कोड उदाहरण 2 के समान है: ध्यान दें कि मुझे AX रजिस्टर में एक पते से दर्शाया गया है। यही है, हम संदर्भ से i पास करते हैं। और यह इस तथ्य के बावजूद कि फोब्वायवल कहा जाता है। लूप का शरीर रनटाइम.न्यूप्रोफ का उपयोग करके फ़ंक्शन को कॉल करता है, लेकिन यह फ़ंक्शन कहां से आता है?

Func1 को कंपाइलर द्वारा बनाया गया है, और यह एक क्लोजर है। कंपाइलर ने क्लोजर कोड को एक अलग फ़ंक्शन के रूप में आवंटित किया है और इसे मुख्य से कॉल करता है। इस आवंटन के साथ मुख्य समस्या यह है कि उपयोग किए जाने वाले चर से कैसे निपटें, लेकिन जो स्पष्ट रूप से तर्क नहीं हैं।

यह फंक 1 का शरीर कैसा दिखता है:

 0x0000 00000 (go-closure.go:14) MOVQ (TLS), CX 0x0009 00009 (go-closure.go:14) CMPQ SP, 16(CX) 0x000d 00013 (go-closure.go:14) JLS 56 0x000f 00015 (go-closure.go:14) SUBQ $16, SP 0x0013 00019 (go-closure.go:14) MOVQ BP, 8(SP) 0x0018 00024 (go-closure.go:14) LEAQ 8(SP), BP 0x001d 00029 (go-closure.go:15) MOVQ "".&i+24(SP), AX 0x0022 00034 (go-closure.go:15) MOVQ (AX), AX 0x0025 00037 (go-closure.go:15) MOVQ AX, (SP) 0x0029 00041 (go-closure.go:15) CALL "".foobyval(SB) 0x002e 00046 (go-closure.go:16) MOVQ 8(SP), BP 0x0033 00051 (go-closure.go:16) ADDQ $16, SP 0x0037 00055 (go-closure.go:16) RET 

यहां यह दिलचस्प है कि फ़ंक्शन में 24 (SP) में एक तर्क है, जो कि int का एक संकेतक है: लाइन MOVQ (AX), AX पर एक नज़र डालें, जो फ़ॉबॉयवल को पास करने से पहले एक मान लेता है। वास्तव में, func1 कुछ इस तरह दिखता है:

 func func1(i *int) { foobyval(*i) }    main   - : for i := 0; i < 5; i++ { go func1(&i) } 

उदाहरण 2 के समकक्ष प्राप्त किया, और यह निष्कर्ष बताते हैं। तकनीकी भाषा में, हम कहेंगे कि मैं एक बंद के अंदर एक मुफ्त चर है और इस तरह के चर गो में संदर्भ द्वारा कैप्चर किए गए हैं।

लेकिन क्या हमेशा ऐसा ही होता है? हैरानी की बात है, जवाब नहीं है। कुछ मामलों में, मुफ्त चर मूल्य द्वारा कब्जा कर लिया जाता है। यहाँ हमारे उदाहरण की एक भिन्नता है:

 for i := 0; i < 5; i++ { ii := i go func() { foobyval(ii) }() } 

यह उदाहरण यादृच्छिक क्रम में 0, 1, 2, 3, 4 का उत्पादन करेगा। लेकिन यहाँ व्यवहार 5 उदाहरण से अलग क्यों है?

यह पता चला है कि यह व्यवहार हेयुरिस्टिक की एक कलाकृति है जिसे गो संकलक उपयोग करता है जब यह क्लोजर के साथ काम करता है।

हम हुड के नीचे देखते हैं

यदि आप गो संकलक की वास्तुकला से परिचित नहीं हैं, तो मेरा सुझाव है कि आप इस विषय पर मेरे शुरुआती लेख पढ़ें: भाग १ , भाग २ ।

कोड को पार्स करके प्राप्त किया जाने वाला विशिष्ट (सार के विपरीत) सिंटैक्स वृक्ष इस तरह दिखता है:

 0: *syntax.CallStmt { . Tok: go . Call: *syntax.CallExpr { . . Fun: *syntax.FuncLit { . . . Type: *syntax.FuncType { . . . . ParamList: nil . . . . ResultList: nil . . . } . . . Body: *syntax.BlockStmt { . . . . List: []syntax.Stmt (1 entries) { . . . . . 0: *syntax.ExprStmt { . . . . . . X: *syntax.CallExpr { . . . . . . . Fun: foobyval @ go-closure.go:15:4 . . . . . . . ArgList: []syntax.Expr (1 entries) { . . . . . . . . 0: i @ go-closure.go:15:13 . . . . . . . } . . . . . . . HasDots: false . . . . . . } . . . . . } . . . . } . . . . Rbrace: syntax.Pos {} . . . } . . } . . ArgList: nil . . HasDots: false . } } 

कहा जाता है फ़ंक्शन फंकलिट नोड द्वारा दर्शाया जाता है, एक स्थिर फ़ंक्शन। जब इस पेड़ को AST (अमूर्त सिंटैक्स ट्री) में बदल दिया जाता है, तो इस निरंतर फ़ंक्शन को एक अलग के रूप में उजागर करना परिणाम होगा। यह noder.funcLit पद्धति में होता है, जो gc / closure.go में रहता है।

फिर पका हुआ चेकर परिवर्तन को पूरा करता है, और हम एएसटी में फ़ंक्शन के लिए निम्नलिखित प्रतिनिधित्व प्राप्त करते हैं:

 main.func1: . DCLFUNC l(14) tc(1) FUNC-func() . DCLFUNC-body . . CALLFUNC l(15) tc(1) . . . NAME-main.foobyval a(true) l(8) x(0) class(PFUNC) tc(1) used FUNC-func(int) . . CALLFUNC-list . . . NAME-main.il(15) x(0) class(PAUTOHEAP) tc(1) used int 

ध्यान दें कि फ़ॉबॉयवल के लिए दिया गया मान NAME-main.i है, अर्थात, हम स्पष्ट रूप से उस फ़ंक्शन से वेरिएबल को इंगित करते हैं जो क्लोजर को लपेटता है।

इस स्तर पर, कंपाइलर स्टेज, जिसे कैप्चरवर कहा जाता है, जो "कैप्चरिंग वैरिएबल" है, ऑपरेशन में आता है। इसका उद्देश्य यह तय करना है कि "बंद चर" पर कब्जा कैसे किया जाए (अर्थात बंद में उपयोग किए जाने वाले मुक्त चर)। यहाँ संगत संकलक समारोह से एक टिप्पणी है, जो भी वर्णन करता है:

// कैप्चरर्स को सभी प्रकार की जाँच के बाद एक अलग चरण में कहा जाता है।
// यह तय करता है कि मूल्य या संदर्भ द्वारा चर पर कब्जा करना है या नहीं।
// हम मान के लिए कैप्चर का उपयोग करते हैं <= 128 बाइट्स जो अब कैप्चर (मूल रूप से स्थिरांक) के बाद मूल्य नहीं बदलते हैं।

जब कैप्चरवार्स को उदाहरण 5 में कहा जाता है, तो यह तय करता है कि लूप वेरिएबल को मुझे संदर्भ द्वारा कैप्चर किया जाना चाहिए, और इसके लिए उपयुक्त ऐडर्केन ध्वज जोड़ता है। एएसटी आउटपुट में इसे देखा जा सकता है:

 FOR l(13) tc(1) . LT l(13) tc(1) bool . . NAME-main.ia(true) g(1) l(13) x(0) class(PAUTOHEAP) esc(h) tc(1) addrtaken assigned used int 

लूप वेरिएबल के लिए, "वैल्यू बाय" सिलेक्शन ह्यूरिस्टिक काम नहीं करता है, क्योंकि कॉल के बाद वैरिएबल अपना वैल्यू बदल देता है (स्पेसिफिकेशन से कोट याद रखें कि लूप वैरिएबल का प्रत्येक पुनरावृत्ति पर उपयोग किया जाता है)। इसलिए, चर मैं संदर्भ द्वारा कब्जा कर लिया है।
हमारे उदाहरण के उस भिन्नता में, जहाँ हमारे पास ii: = i, ii का उपयोग नहीं किया गया है और इसलिए इसे मूल्य [5] द्वारा पकड़ लिया गया है।

इस प्रकार, हम अप्रत्याशित तरीके से भाषा की दो अलग-अलग विशेषताओं को ओवरलैप करने का एक आश्चर्यजनक उदाहरण देखते हैं। लूप के प्रत्येक पुनरावृत्ति पर एक नए चर का उपयोग करने के बजाय, गो एक ही पुन: उपयोग करता है। यह बदले में, उत्तराधिकार की ट्रिगर और संदर्भ द्वारा कब्जा करने की पसंद की ओर जाता है, और यह एक अप्रत्याशित परिणाम की ओर जाता है। Go FAQ कहता है कि यह व्यवहार एक डिज़ाइन त्रुटि हो सकती है।

भाषा को डिज़ाइन करते समय यह व्यवहार (एक नए चर का उपयोग न करें) शायद एक गलती है। शायद हम इसे भविष्य के संस्करणों में ठीक कर देंगे, लेकिन पिछड़ी संगतता के कारण हम गो संस्करण 1 में कुछ भी नहीं कर सकते हैं।

यदि आप समस्या के बारे में जानते हैं, तो आप इस रेक पर कदम नहीं रखेंगे। लेकिन ध्यान रखें कि मुक्त चर को हमेशा संदर्भ द्वारा कैप्चर किया जा सकता है। त्रुटियों से बचने के लिए, सुनिश्चित करें कि गोरआउट का उपयोग करते समय केवल पढ़ने योग्य चर ही कैप्चर किए जाते हैं। डेटा उड़ानों के साथ संभावित मुद्दों के कारण भी यह महत्वपूर्ण है।

[१] कुछ पाठकों ने देखा है कि, कड़ाई से बोलते हुए, गो में "संदर्भ से गुजर" की कोई अवधारणा नहीं है, क्योंकि सब कुछ मूल्य सहित पारित किया गया है, जिसमें संकेत भी शामिल हैं। इस लेख में, जब आप "संदर्भ द्वारा पास" देखते हैं, तो मेरा मतलब है "पता द्वारा पास" और यह कुछ मामलों में स्पष्ट है (जैसे कि एक फ़ंक्शन को पास करना और n करना जो * int की अपेक्षा रखता है), और कुछ मामलों में निहित है, जैसे कि बाद में। लेख के कुछ भाग।

[२] इसके बाद, मैं समय का उपयोग करता हूं। सोते समय सभी गोरोइटिन को पूरा करने के लिए एक त्वरित और गंदे तरीके के रूप में सोएं। इसके बिना, मुख्य समाप्त हो जाएगा इससे पहले कि गोरोनाइट काम करना शुरू कर दें। ऐसा करने का सही तरीका है कि आप वेटग्रुप या किए गए चैनल जैसी किसी चीज़ का उपयोग करें।

[३] इस लेख में सभी उदाहरणों के लिए असेंबलर प्रतिनिधित्व को गो टूल कंपाइल -l -S कमांड का उपयोग करके प्राप्त किया गया था। -L ध्वज फंक्शन इनलाइनिंग को अक्षम करता है और कोडांतरक कोड को अधिक पठनीय बनाता है।

[४] कॉल के माध्यम से जाने के बाद से फ़ॉबीवल को सीधे नहीं कहा जाता है। इसके बजाय, पता runtime.newproc फ़ंक्शन के लिए दूसरे तर्क (16 (SP)) के रूप में पास किया गया है, और फ़ॉबॉयवल (इस मामले में) का तर्क स्टैक ऊपर जाता है।

[५] अभ्यास के रूप में, आईओ = १० को लूप की अंतिम पंक्ति के रूप में जोड़ें (कॉल करने के बाद)। आपका निष्कर्ष क्या था? क्यों?