इवेंट मशीन जीवन चक्र की रक्षा करती है

अस्वीकरण: यह लेख गैर-स्पष्ट समस्या के लिए एक गैर-स्पष्ट समाधान का वर्णन करता है। दौड़ने से पहले अंडे इसे व्यवहार में लाएं, मैं लेख को अंत तक पढ़ने और दो बार सोचने की सलाह देता हूं।

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

राज्य का प्रबंधन क्यों?

शुरू करने के लिए, आइए अवधारणा को ही परिभाषित करें। एक राज्य का सबसे सरल उदाहरण: फाइलें और विभिन्न कनेक्शन। आप बस एक फ़ाइल ले और पढ़ नहीं सकते। इसे पहले खोला जाना चाहिए, और अंत में यह वांछनीय है बंद करना सुनिश्चित करें। यह पता चला है कि वर्तमान कार्रवाई पिछली कार्रवाई के परिणाम पर निर्भर करती है: पढ़ना उद्घाटन पर निर्भर करता है। बचाया परिणाम राज्य है।

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

हालांकि, एक ऐसी संपत्ति है जो आपको कठिनाइयों से रूबरू कराती है। एक राज्य को आपको कार्यों के एक विशिष्ट क्रम का पालन करने की आवश्यकता होती है। सामान्य तौर पर, ऐसी स्थितियों से बचा जाना चाहिए, लेकिन यह हमेशा संभव नहीं है। एक उदाहरण कार्यक्रम वस्तुओं का जीवन चक्र है। अच्छे राज्य प्रबंधन के लिए धन्यवाद, एक जटिल जीवन चक्र के साथ वस्तुओं का अनुमानित व्यवहार प्राप्त कर सकता है।

अब आइए जानें कि इसे कैसे ठंडा किया जाए ।

समस्याओं को हल करने के तरीके के रूप में स्वचालित

जब लोग राज्यों के बारे में बात करते हैं, तो राज्य की मशीनें तुरंत दिमाग में आ जाती हैं। यह तार्किक है, क्योंकि एक ऑटोमेटन एक राज्य का प्रबंधन करने का सबसे प्राकृतिक तरीका है।

मैं ऑटोमेटा के सिद्धांत में नहीं उतरूंगा , इंटरनेट पर पर्याप्त जानकारी से अधिक है।

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

समझने की मुख्य बात यह है कि एक ऑटोमेटन एक कड़ाई से विशिष्ट समस्या का समाधान है। इसलिए, इसे सभी समस्याओं का उपाय मानने से पहले, आपको कार्य को पूरी तरह से समझ लेना चाहिए। विशेष रूप से, वह इकाई जिसे आप नियंत्रित करना चाहते हैं:

• राज्यों - जीवन चक्र;
• घटनाओं - क्या वास्तव में प्रत्येक राज्य के लिए संक्रमण का कारण बनता है;
• कार्य परिणाम - आउटपुट डेटा;
• निष्पादन मोड (सिंक्रोनस / एसिंक्रोनस);
• मुख्य उपयोग के मामले।

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

वास्तविक उदाहरण

इसे स्पष्ट करने के लिए, मैं phono लाइब्रेरी से एक उदाहरण का विश्लेषण करूंगा।

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

और हम क्या प्रबंध कर रहे हैं?

phono डीएसपी पाइपलाइन पर आधारित है। इसमें प्रसंस्करण के तीन चरण होते हैं। प्रत्येक चरण में एक से लेकर कई घटक शामिल हो सकते हैं:

1. pipe.Pump (अंग्रेजी पंप) ध्वनि प्राप्त करने का एक अनिवार्य चरण है, हमेशा केवल एक घटक।
2. pipe.Processor (अंग्रेजी हैंडलर) - 0 से एन घटकों के लिए ध्वनि प्रसंस्करण का एक वैकल्पिक चरण।
3. pipe.Sink सिंक (अंग्रेजी सिंक) - 1 से एन घटकों तक ध्वनि संचरण का एक अनिवार्य चरण।

दरअसल, हम कन्वेयर जीवन चक्र का प्रबंधन करेंगे।

जीवन चक्र

यह वही है जो pipe.Pipe । pipe.Pipe राज्य आरेख जैसा दिखता है।

इटैलिक आंतरिक निष्पादन तर्क के कारण संक्रमण का संकेत देते हैं। बोल्ड - घटनाओं के कारण संक्रमण। आरेख दिखाता है कि राज्यों को 2 प्रकारों में विभाजित किया गया है:

• मौन राज्यों - ready और paused , आप केवल घटना से उन से कूद सकते हैं
• सक्रिय स्थिति - running और pausing , घटना से संक्रमण और निष्पादन तर्क के कारण

कोड के विस्तृत विश्लेषण से पहले, सभी राज्यों के उपयोग का एक स्पष्ट उदाहरण:

 // PlayWav  .wav    portaudio  -. func PlayWav(wavFile string) error { bufferSize := phono.BufferSize(512) //      w, err := wav.NewPump(wavFile, bufferSize) //  wav pump if err != nil { return err } pa := portaudio.NewSink( //  portaudio sink bufferSize, w.WavSampleRate(), w.WavNumChannels(), ) p := pipe.New( //  pipe.Pipe    ready w.WavSampleRate(), pipe.WithPump(w), pipe.WithSinks(pa), ) p.Run() //    running   p.Run() errc := p.Pause() //    pausing   p.Pause() err = pipe.Wait(errc) //     paused if err != nil { return err } errc = p.Resume() //    running   p.Resume() err = pipe.Wait(errc) //     ready if err != nil { return err } return pipe.Wait(p.Close()) //      } 

अब, पहले चीजें पहले।

सभी स्रोत कोड रिपॉजिटरी में उपलब्ध हैं।

राज्यों और घटनाओं

सबसे महत्वपूर्ण बात के साथ शुरू करते हैं।

 // state      . type state interface { listen(*Pipe, target) (state, target) //    transition(*Pipe, eventMessage) (state, error) //   } // idleState  .        . type idleState interface { state } // activeState  .         //   . type activeState interface { state sendMessage(*Pipe) state //    } //  . type ( idleReady struct{} activeRunning struct{} activePausing struct{} idlePaused struct{} ) //  . var ( ready idleReady running activeRunning paused idlePaused pausing activePausing ) 

अलग-अलग प्रकारों के लिए धन्यवाद, प्रत्येक राज्य के लिए संक्रमण भी अलग-अलग घोषित किए जाते हैं। इससे विशाल बच जाता है सॉस नेस्टेड switch साथ संक्रमण कार्य करता है। राज्यों के पास स्वयं कोई डेटा या तर्क नहीं है। उनके लिए, आप पैकेज स्तर पर चर घोषित कर सकते हैं ताकि आप हर बार ऐसा न करें। बहुरूपता के लिए state इंटरफ़ेस की आवश्यकता है। activeState थोड़ी देर बाद idleState और idleState बारे में बात idleState ।

हमारी मशीन का दूसरा सबसे महत्वपूर्ण हिस्सा घटनाओं है।

 // event  . type event int //  . const ( run event = iota pause resume push measure cancel ) // target      . type target struct { state idleState //   errc chan error //   ,     } // eventMessage   ,    . type eventMessage struct { event //   params params //   components []string // id  target //      } 

यह समझने के लिए कि target प्रकार की आवश्यकता क्यों है, एक साधारण उदाहरण पर विचार करें। हमने एक नया कन्वेयर बनाया है, यह ready । अब इसे p.Run() साथ p.Run() । run इवेंट को मशीन में भेजा जाता है, पाइपलाइन running स्टेट में जाती है। जब कन्वेयर समाप्त हो गया है तो कैसे पता करें? यह वह जगह है जहाँ target प्रकार हमारी मदद करेगा। यह इंगित करता है कि घटना के बाद आराम करने की क्या स्थिति है। हमारे उदाहरण में, काम पूरा होने के बाद, पाइपलाइन फिर से ready स्थिति में प्रवेश करेगी। आरेख में एक ही बात:

अब राज्यों के प्रकारों के बारे में अधिक। अधिक सटीक रूप से, idleState और idleState activeState बारे में। चलो विभिन्न प्रकार के चरणों के लिए listen(*Pipe, target) (state, target) कार्यों को देखें:

 // listen     ready. func (s idleReady) listen(p *Pipe, t target) (state, target) { return p.idle(s, t) } // listen     running. func (s activeRunning) listen(p *Pipe, t target) (state, target) { return p.active(s, t) } 

एक संक्रमण के लिए प्रतीक्षा करने के लिए pipe.Pipe के अलग-अलग कार्य हैं! वहाँ क्या है?

 // idle     .    . func (p *Pipe) idle(s idleState, t target) (state, target) { if s == t.state || s == ready { t = t.dismiss() //  ,  target } for { var newState state var err error select { case e := <-p.events: //   newState, err = s.transition(p, e) //    if err != nil { e.target.handle(err) } else if e.hasTarget() { t.dismiss() t = e.target } } if s != newState { return newState, t // ,    } } } // active     .     , //   . func (p *Pipe) active(s activeState, t target) (state, target) { for { var newState state var err error select { case e := <-p.events: //   newState, err = s.transition(p, e) //    if err != nil { //  ? e.target.handle(err) // ,    } else if e.hasTarget() { // ,  target t.dismiss() //   t = e.target //   } case <-p.provide: //     newState = s.sendMessage(p) //    case err, ok := <-p.errc: //   if ok { //   ,  interrupt(p.cancel) //   t.handle(err) //    } //    ,  return ready, t //    ready } if s != newState { return newState, t // ,    } } } 

इस प्रकार, हम विभिन्न राज्यों में विभिन्न चैनलों को सुन सकते हैं। उदाहरण के लिए, यह आपको एक ठहराव के दौरान संदेश नहीं भेजने की अनुमति देता है - हम सिर्फ संबंधित चैनल को नहीं सुनते हैं।

मशीन का कंस्ट्रक्टर और स्टार्ट

 // New      . //      ready. func New(sampleRate phono.SampleRate, options ...Option) *Pipe { p := &Pipe{ UID: phono.NewUID(), sampleRate: sampleRate, log: log.GetLogger(), processors: make([]*processRunner, 0), sinks: make([]*sinkRunner, 0), metrics: make(map[string]measurable), params: make(map[string][]phono.ParamFunc), feedback: make(map[string][]phono.ParamFunc), events: make(chan eventMessage, 1), //    cancel: make(chan struct{}), //     provide: make(chan struct{}), consume: make(chan message), } for _, option := range options { //   option(p)() } go p.loop() //    return p } 

आरंभीकरण और कार्यात्मक विकल्पों के अलावा, मुख्य चक्र के साथ एक अलग गोरआउट की शुरुआत होती है। खैर, उसे देखो:

 // loop ,     nil . func (p *Pipe) loop() { var s state = ready //   t := target{} for s != nil { s, t = s.listen(p, t) //      p.log.Debug(fmt.Sprintf("%v is %T", p, s)) } t.dismiss() close(p.events) //    } // listen     ready. func (s idleReady) listen(p *Pipe, t target) (state, target) { return p.idle(s, t) } // transition       . func (s idleReady) transition(p *Pipe, e eventMessage) (state, error) { switch e.event { case cancel: interrupt(p.cancel) return nil, nil case push: e.params.applyTo(p.ID()) p.params = p.params.merge(e.params) return s, nil case measure: for _, id := range e.components { e.params.applyTo(id) } return s, nil case run: if err := p.start(); err != nil { return s, err } return running, nil } return s, ErrInvalidState } 

कन्वेयर बनाया गया है और घटनाओं की प्रतीक्षा में जम गया है।

काम करने का समय

p.Run() कॉल करें!

 // Run   run  . //     pipe.Close  . func (p *Pipe) Run() chan error { runEvent := eventMessage{ event: run, target: target{ state: ready, //    errc: make(chan error, 1), }, } p.events <- runEvent return runEvent.target.errc } // listen     running. func (s activeRunning) listen(p *Pipe, t target) (state, target) { return p.active(s, t) } // transition       . func (s activeRunning) transition(p *Pipe, e eventMessage) (state, error) { switch e.event { case cancel: interrupt(p.cancel) err := Wait(p.errc) return nil, err case measure: e.params.applyTo(p.ID()) p.feedback = p.feedback.merge(e.params) return s, nil case push: e.params.applyTo(p.ID()) p.params = p.params.merge(e.params) return s, nil case pause: return pausing, nil } return s, ErrInvalidState } // sendMessage   . func (s activeRunning) sendMessage(p *Pipe) state { p.consume <- p.newMessage() return s } 

running संदेश उत्पन्न करता है और पाइपलाइन के पूरा होने तक चलता है।

कॉफी ब्रेक

कन्वेयर के निष्पादन के दौरान, हम इसे रोक सकते हैं। इस स्थिति में, पाइपलाइन नए संदेश उत्पन्न नहीं करेगा। ऐसा करने के लिए, p.Pause() विधि को कॉल करें।

 // Pause   pause  . //     pipe.Close  . func (p *Pipe) Pause() chan error { pauseEvent := eventMessage{ event: pause, target: target{ state: paused, //    errc: make(chan error, 1), }, } p.events <- pauseEvent return pauseEvent.target.errc } // listen     pausing. func (s activePausing) listen(p *Pipe, t target) (state, target) { return p.active(s, t) } // transition       . func (s activePausing) transition(p *Pipe, e eventMessage) (state, error) { switch e.event { case cancel: interrupt(p.cancel) err := Wait(p.errc) return nil, err case measure: e.params.applyTo(p.ID()) p.feedback = p.feedback.merge(e.params) return s, nil case push: e.params.applyTo(p.ID()) p.params = p.params.merge(e.params) return s, nil } return s, ErrInvalidState } // sendMessage   .   -, //      .    //    ,      .  , // ,   , : // 1.     // 2.      func (s activePausing) sendMessage(p *Pipe) state { m := p.newMessage() if len(m.feedback) == 0 { m.feedback = make(map[string][]phono.ParamFunc) } var wg sync.WaitGroup //     wg.Add(len(p.sinks)) //   Sink for _, sink := range p.sinks { param := phono.ReceivedBy(&wg, sink.ID()) // - m.feedback = m.feedback.add(param) } p.consume <- m //   wg.Wait() // ,     return paused } 

जैसे ही सभी प्राप्तकर्ता संदेश प्राप्त करते हैं, पाइपलाइन paused स्थिति में paused जाएगी। यदि संदेश अंतिम है, तो ready स्थिति में संक्रमण होता है।

वापस काम पर!

paused अवस्था से बाहर निकलने के लिए p.Resume() कॉल करें।

 // Resume   resume  . //     pipe.Close  . func (p *Pipe) Resume() chan error { resumeEvent := eventMessage{ event: resume, target: target{ state: ready, errc: make(chan error, 1), }, } p.events <- resumeEvent return resumeEvent.target.errc } // listen     paused. func (s idlePaused) listen(p *Pipe, t target) (state, target) { return p.idle(s, t) } // transition       . func (s idlePaused) transition(p *Pipe, e eventMessage) (state, error) { switch e.event { case cancel: interrupt(p.cancel) err := Wait(p.errc) return nil, err case push: e.params.applyTo(p.ID()) p.params = p.params.merge(e.params) return s, nil case measure: for _, id := range e.components { e.params.applyTo(id) } return s, nil case resume: return running, nil } return s, ErrInvalidState } 

यहां सब कुछ तुच्छ है, पाइपलाइन फिर से running है।

ऊपर कर्ल करें

कन्वेयर को किसी भी राज्य से रोका जा सकता है। इसके लिए p.Close() ।

 // Close   cancel  . //      . //    ,   . func (p *Pipe) Close() chan error { resumeEvent := eventMessage{ event: cancel, target: target{ state: nil, //   errc: make(chan error, 1), }, } p.events <- resumeEvent return resumeEvent.target.errc } 

इसकी जरूरत किसे है?

हर किसी के लिए नहीं। राज्य को कैसे प्रबंधित किया जाए, यह समझने के लिए, आपको अपने कार्य को समझने की आवश्यकता है। ऐसी दो परिस्थितियाँ हैं जिनमें आप एक घटना-आधारित अतुल्यकालिक मशीन का उपयोग कर सकते हैं:

1. जटिल जीवन चक्र - गैर-रैखिक संक्रमण वाले तीन या अधिक राज्य हैं।
2. अतुल्यकालिक निष्पादन का उपयोग किया जाता है।

यद्यपि ईवेंट मशीन समस्या का हल करती है, लेकिन यह एक जटिल पैटर्न है। इसलिए, इसका उपयोग बहुत सावधानी से किया जाना चाहिए और सभी पेशेवरों और विपक्षों की पूरी समझ के बाद ही किया जाना चाहिए।

संदर्भ

• phono
• लीकर रॉब पाइक