मुझे एरलांग के बारे में बहुत सीमित जानकारी मिली है, लेकिन जहां तक मैं समझता हूं, यह बहुत कम लागत के साथ "प्रक्रियाओं" को जन्म दे सकता है।दृश्यों के पीछे Erlang प्रक्रियाएं क्या हैं?
तो मुझे आश्चर्य है, दृश्यों के पीछे उन "प्रक्रियाओं" क्या हैं?
क्या वे फाइबर हैं? धागे? निरंतरता?
इसके अलावा, Erlang दस्तावेज़ से:
Erlang प्रक्रियाओं हल्के वजन (बढ़ने और गतिशील रूप से हटना) छोटे स्मृति पदचिह्न के साथ, तेजी से बना सकते हैं और समाप्त और शेड्यूलिंग भूमि के ऊपर कम है करने के लिए कर रहे हैं।
स्रोत: http://www.erlang.org/doc/reference_manual/processes.html
आप भी इस के लिए देखने के लिए चाहते हो सकता है:
http://www.defmacro.org/ramblings/concurrency.html
जब Erlang प्रक्रियाओं के बारे में बात कर रहे हैं, यह कहते हैं:
Erlang प्रक्रियाओं हल्के वजन धागे हैं। वे को शुरू करने और नष्ट करने के लिए बहुत सस्ते हैं और के लिए बहुत तेज हैं क्योंकि हुड के तहत स्विच वे बस कार्य कर रहे हैं। एक सामान्य आधुनिक डेस्कटॉप कंप्यूटर पर चल रहे एरलांग सिस्टम कई हजारों प्रक्रियाओं के बीच स्विच कर सकता है। प्रक्रियाओं को दर्जन फ़ंक्शन कॉल के प्रत्येक जोड़े को स्विच किया जाता है जो कम दानेदार बनाता है लेकिन को सामान्य रूप से संदर्भ स्विचिंग पर बर्बाद कर देता है।
तो यह फाइबर से अलग कैसे है? –
उदाहरण के लिए, रूबी फाइबर अलग-अलग कोर/सीपीयू पर एक साथ नहीं चल सकते हैं (जहां तक मुझे पता है, अगर मैं गलत हूं तो मुझे सही करें), जबकि एरलांग उस पर बहुत अच्छा है। –
क्या रूबी सीमा अधिक नहीं है? आप Win32 में थ्रेड से/फाइबर बना सकते हैं। और इस प्रकार उन्हें कई कोरों पर चलाने में कोई समस्या नहीं होनी चाहिए? –
वे Lightweight Processes हैं।
मेरा प्रश्न Technically why is processes in Erlang more efficient than OS threads भी देखें।
असल में वे थ्रेड हैं;) उनके लिए एक पता स्थान।
नहीं वे नहीं हैं। Erlang प्रक्रियाओं को लागू करने के लिए धागे बहुत भारी वजन है। (मैंने डाउनवोट नहीं किया, बीटीडब्ल्यू।) –
तो वे पूरी तरह से एक धागे के समय से नकल कर रहे हैं? क्षमा करें, ऐसा लगता है कि कंप्यूटर में एक से अधिक कोर होने पर ridiculo9us अक्षम होता है;) – TomTom
एरलांग एसएमपी प्रति सीपीयू कोर एक थ्रेड है। एरलांग वीएम प्रत्येक प्रक्रिया को एक पृथक पता स्थान, आईपीसी और टाइमशेयरिंग प्रदान करता है। – cthulahoops
मैं एक निश्चित स्रोत नहीं मिला है, लेकिन से मैं क्या समझ:
एक अनुसूचक (जैसे या एक से अधिक शेड्यूलर कि सहयोगात्मक कार्य) जो erlang प्रक्रिया पर शुरू करने के लिए निर्धारित करता है कि नहीं है जो ओएस धागा।
इन प्रक्रियाओं एक उगने वाली दाढ़ी ढेर (शायद में एक प्रस्तावना प्रत्येक कार्यों यदि आवश्यक हो तो ढेर आवंटित करता है) होता है अतः वे बहुत अधिक स्मृति का उपभोग नहीं करते जब तक कि वे इसकी आवश्यकता है।
वे चाहे वे डेटा पर इंतजार कर या समय की पर्याप्त मात्रा (कुछ कार्यों में हो सकता है प्रस्तावना कोड समय कितना बीत जाने पर देखने के लिए जाँच करता है) के लिए मार डाला है पर निर्भर करता है नियोजक को वापस उपज। धागे के विपरीत, वे छूट नहीं लेते हैं?
प्रत्येक प्रक्रिया विभिन्न पृष्ठों से या एक अलग संभाजक से स्मृति आबंटित करता है, तो यह स्मृति साझा करने के लिए ( समान तरीके है कि ओएस प्रक्रियाओं स्मृति साझा करने से बच में) संभव नहीं है।
मुमकिन भी अलग allocators या erlang प्रक्रिया प्रति पृष्ठों भी कचरा संग्रहण के साथ में मदद मिलेगी, और मामले कि इस प्रक्रिया समाप्त हो जाती है, तो पृष्ठों किसी भी कचरा संग्रहण करने के लिए बिना वापस किया जा सकता में: http://prog21.dadgum.com/16.html
संबंधित: http://stackoverflow.com/questions/1934707/what-other-systems-beside-erlang-are-based-on-green-processes – jldupont
संबंधित: http://stackoverflow.com/questions/1 9 47180/क्या-अंतर-बीच-हरे-धागे-और-erlangs-process – jldupont