Design: pThreads कोई ईटीए ?

अगली कुछ तिमाहियों में कुछ समय शायद उतना ही सटीक होगा जितना कोई कह सकता है। लेकिन कृपया मुद्दों को दर्ज करने के लिए इश्यू ट्रैकर को सुरक्षित रखें।

इस प्रोजेक्ट में कोई मेलिंग सूची या अन्य फ़ोरम नहीं है, इसलिए इश्यू ट्रैकर ही एकमात्र ऐसा स्थान है जहाँ लोग डिज़ाइन प्रक्रिया के प्रश्न पूछ सकते हैं। ऐसा स्थान होना महत्वपूर्ण है जहां लोग प्रश्न पूछ सकें, इसलिए मैं लोगों को प्रश्न पूछने के लिए समस्या ट्रैकर का उपयोग जारी रखने के लिए प्रोत्साहित करता हूं।

@sunfishcode , काफी उचित है, लेकिन फिर मेरा सुझाव है कि हम ऐसी सूची बनाएं। मुझे नहीं लगता कि एक मुद्दा ट्रैकर उसके लिए एक उचित विकल्प है।

w3 सार्वजनिक सूची है। हालांकि इस पर ज्यादा ट्रैफिक नहीं लगता है। मुझे विश्वास है कि एक आईआरसी भी है? मुझे लगता है कि यह किसी समय वेबसाइट पर था, लेकिन यह अच्छा होगा यदि वे दोनों सीधे वेबसाइट के सामुदायिक अनुभाग से जुड़े हों। मैं एक मुद्दा खोलूंगा लेकिन मुझे यकीन नहीं है कि आप कौन से रास्ते पसंद करेंगे ~ उजागर ~ जनता से जुड़े

यहां निर्देश:

• https://github.com/WebAssembly/design/blob/master/Contributing.md
• http://webassembly.org/community/feedback/

हम लोगों को जीथब का उपयोग करने के लिए मार्गदर्शन कर रहे हैं। हर कोई इसे पसंद नहीं करता है, लेकिन कई से एक जगह होना बेहतर है।

हाय @ रॉसबर्ग-क्रोमियम और आपके समय पर उत्तर के लिए धन्यवाद।

लेकिन कृपया मुद्दों को दर्ज करने के लिए इश्यू ट्रैकर को सुरक्षित रखें।

जैसा कि @jfbastien द्वारा बताया गया है, मैंने यहां पूछा क्योंकि यह मानक तरीके से करने के लिए सबसे अच्छी जगह है।
इसके अलावा, थ्रेड सपोर्ट एक डिज़ाइन सुविधा है जो webAssembly के लिए एक मेक या ब्रेक है।
लोगो संदर्भ से अधिक और "इसे जावा में क्यों लागू नहीं किया गया है" मुझे मुद्दों के रूप में उठाया गया है।

अगर मैं गलत हूं तो कृपया मुझे बताएं कि साझा मेमोरी/थ्रेड कार्यान्वयन का पालन कहां करें।
यह एक खुली प्रक्रिया होनी चाहिए, इसलिए मैं अपनी बात रखना चाहता हूं।

--आर

@RobertoMalatesta हम सहमत हैं कि धागे बहुत महत्वपूर्ण हैं, लेकिन उन्हें WebAssembly के न्यूनतम-व्यवहार्य उत्पाद में समेटने की तुलना में उन्हें सही करना अधिक महत्वपूर्ण था। हमारा तर्क सरल है: asm.js ने इस सुविधा के बिना सफलता का आनंद लिया है।

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

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

कहा जा रहा है, हम WebAssembly में JavaScript SharedArrayBuffer दृष्टिकोण को कमोबेश अपनाने की उम्मीद करते हैं। हम में से बहुत से लोग शुरू से ही उस युक्ति से जुड़े रहे हैं। यह सी ++ के समान निम्न-स्तरीय क्षमताओं को जोड़ देगा, साथ ही एक फ्यूटेक्स-जैसी एपीआई भी। इसमें क्रमिक स्थिरता की तुलना में अधिक मेमोरी ऑर्डरिंग के साथ बढ़ने की गुंजाइश है। इसके लिए एक औपचारिक मेमोरी मॉडल बनाने का काम चल रहा है।

SAB TC39 में "चरण 4" पर है, जिसका अर्थ है कि यह हो चुका है, जहाज के लिए तैयार है, और उपयोग के लिए तैयार है। मुझे उम्मीद है कि इसे WebAssembly में अपनाना बहुत मुश्किल नहीं होगा।

@jfbastien अंतर्दृष्टिपूर्ण जानकारी के लिए धन्यवाद।

कहा जा रहा है, हम WebAssembly में JavaScript SharedArrayBuffer दृष्टिकोण को कमोबेश अपनाने की उम्मीद करते हैं। (...)
SAB TC39 में "चरण 4" पर है, जिसका अर्थ है कि यह हो चुका है, जहाज के लिए तैयार है, और उपयोग के लिए तैयार है। मुझे उम्मीद है कि इसे WebAssembly में अपनाना बहुत मुश्किल नहीं होगा।

महान। मैं इसे बहुत सारे सी ++ कोड के साथ किक-टायर करने के लिए उत्सुक हूं जो बस थ्रेडिंग के लिए भूखा है।
मैं नियमित रूप से अपने टीएस/जेएस अनुप्रयोगों में वेबवर्कर्स का उपयोग करता हूं और मुझे कहना है कि मैं उनका प्रशंसक नहीं हूं, लेकिन वे पहली शुरुआत के रूप में जा सकते हैं।

थ्रेड्स बहुत महत्वपूर्ण हैं, लेकिन उन्हें WebAssembly के न्यूनतम-व्यवहार्य उत्पाद में समेटने की तुलना में उन्हें ठीक करना अधिक महत्वपूर्ण था। हमारा तर्क सरल है: asm.js ने इस सुविधा के बिना सफलता का आनंद लिया है।

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

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

लंबे समय तक एमस्क्रिप्टन के उपयोगकर्ता के रूप में, मैं WebAssembly को जावास्क्रिप्ट एप्लिकेशन स्टैक सीमा से अधिक डिकूप्ड देखना चाहता हूं:

Wasm केवल 1) उच्चतम प्रदर्शन का लक्ष्य रखना चाहिए और 2) कुछ पॉज़िक्स/यूनिक्स/बीएसडी मानक के साथ सॉकेट, मेमोरी/थ्रेड्स, जीडीआई, एफएस प्रदान करें। इस तरह, यह एक पतली ओएस जैसी परत होगी जो मोबाइल उपकरणों में एकीकृत लक्ष्य प्लेटफॉर्म के रूप में और सर्वर में क्लाउड-तैनाती योग्य अनुप्रयोगों के लिए प्रतिस्पर्धा करने के लिए एम्बेड करने योग्य होगी।

क्या यह दिशा wasm एक दीर्घकालिक भविष्य की ओर अग्रसर है या मैं पूरी तरह से नाव को याद कर रहा हूँ?

आपके काम के लिए फिर से धन्यवाद,

रॉबर्टो

वासम को निश्चित रूप से कुछ स्टैक सीमाओं से अलग किया जाता है क्योंकि हम स्थानीय लोगों को कैसे अलग करते हैं, जैसे कि एलएलवीएम जैसे कंपाइलर को उपयोगकर्ता-सुलभ मेमोरी में डालने की आवश्यकता होती है।

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

कहा जा रहा है, आपके सटीक विचारों के बारे में अधिक जानकारी प्राप्त करना अच्छा होगा। उपयोग का मामला क्या है, आप C++ में इसके आसपास कैसे काम करते हैं, और wasm कार्यान्वयन इसे कैसे करेंगे?

मुझे उम्मीद नहीं है कि आप सभी उत्तरों के साथ आएंगे! अभी जो दिमाग में आता है। Fwiw C++ में स्टैक सीमा के लिए कुछ प्रस्ताव हैं। SG14 उपसमूह देखें।

कम विवरण के लिए क्षमा करें, मैं के अंतर्गत हूं। बाद में बेहतर जवाब देंगे!

कम विवरण के लिए क्षमा करें, मैं एक :baby:: burito :के अंतर्गत हूँ। बाद में बेहतर जवाब देंगे!

आप बेबी बर्टिटो के अधीन हैं? ज़ोर - ज़ोर से हंसना

@qwertie

आप बेबी बर्टिटो के अधीन हैं? ज़ोर - ज़ोर से हंसना

सचमुच, एक लपेटा हुआ बच्चा।

हाय @jfbastien ,

आपके सटीक विचारों के बारे में अधिक जानकारी प्राप्त करना अच्छा होगा। उपयोग का मामला क्या है, आप C++ में इसके आसपास कैसे काम करते हैं, और wasm कार्यान्वयन इसे कैसे करेंगे?

आम तौर पर मेरा उपयोग मामला सिमुलेशन सॉफ़्टवेयर के निर्माण पर होता है, कम्प्यूटेशनल भाग पर केवल मशीन होने की सीमा होती है, सी ++, सी/ओपनसीएल और जीपीयू प्रौद्योगिकियों के लिए धन्यवाद।

सामने के छोर पर एचटीएमएल5+सीएसएस+जावास्क्रिप्ट+टाइपस्क्रिप्ट मध्य-बड़े जटिल अनुप्रयोगों को विकसित करने का एक वैध, सिद्ध, पोर्टेबल तरीका साबित हुआ है।

_ T वह JS वेब स्टैक (टाइपस्क्रिप्ट जैसी संरचित भाषा के अतिरिक्त) इन दिनों इतना अच्छा है कि मुझे अधिकांश अनुप्रयोगों के लिए emscripten या कोशिश wasm का सहारा लेने की आवश्यकता महसूस नहीं होती है।_

मैं लगभग पूरी तरह से उच्च स्तरीय लक्ष्यों और वेब असेंबली उपयोग के मामलों और गैर-वेब एम्बेडिंग दस्तावेज़ पर और भी अधिक पर सहमत हूं।

_ W ebAssembly एक प्रासंगिक तकनीक होगी (कम से कम मेरे लिए) यदि यह तेज़ होने की अनुमति देगी (मूल सी ऐप की हड्डी के साथ, 5% ओवरहेड कहें) अधिक मेमोरी और अधिक स्वतंत्र रूप से उपयोग करें, बंदरगाहों/सॉकेट को पूरी तरह कार्यान्वित करें और किसी भी सामान्य OS की तरह थ्रेड चलाने की अनुमति देता है।_

वासम मशीन आकार में बहुत धीमी, तेज और भविष्य कहनेवाला होनी चाहिए, इसलिए कृपया इसमें न रहें एक जीसी: जीसी आईटी की पोंजी योजना है: आप कर्ज लेते हैं और आवंटन की परवाह नहीं करते हैं जब तक कि बहुत देर न हो जाए और आप चक्र खो दें . इसके अलावा, अगर हमारे पास एक सुपरपरफॉर्मिंग वासम कोर मशीन है तो उसके ऊपर एक जीसी बनाया जा सकता है।

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

कहीं मोज़िला साइट पर मैंने मूल डोम हेरफेर को लागू करने पर दस्तावेज़ देखे: मुझे नहीं लगता कि यह बहुत उपयोगी होगा क्योंकि डोम हेरफेर स्वाभाविक रूप से अनुक्रमिक है और यह एचटीएमएल 5/सीएसएस/जेएस स्टैक के सबसे अधिक समय लेने वाले पहलुओं में से एक है: यदि मैं सुपरफास्ट मल्टीथ्रेडेड वासम लिखता हूं ताकि मेरे डीओएम कतार में क्रमबद्ध प्रतीक्षा में बदलाव कर सकें, फिर सभी प्रदर्शन खत्म हो गए हैं और यह सी/सी ++ का उपयोग करने से कुछ टाइपस्क्रिप्ट को बेहतर तरीके से ट्रांसपाइल करता है। इस मामले में मैं सीधे ओपनजीएल एक्सेस का पक्ष लेता हूं (पहले कुछ वेबजीएल कार्यान्वयन के साथ ओपनजीएल मूल)। ग्राफिक कार्ड तक पहुंच कम या बिना ओवरहेड के GPU/CUDA क्षमताओं की पेशकश करने के लिए उपयोगी साबित होगी।
(बस इस पर जाँच करने के लिए गया और इस पर # 273 से निपटने का मुद्दा मिला)

प्रत्येक विक्रेता और स्वतंत्र द्वारा साझा की गई एक छोटी वासम मशीन मोबाइल विकास के दुःस्वप्न को भी हल कर सकती है, जहां आपके पास विभिन्न ओएस और संस्करणों और आर्किटेक्चर के लिए कम से कम 4 टूलचेन हैं।
ग्राफिक और इनपुट सुविधाएं अलग-अलग हो सकती हैं लेकिन हम एक wasm तक विकसित करने में सक्षम होंगे और फिर सुविधाओं APIs को क्वेरी करेंगे, या यहां तक ​​​​कि एक ही एप्लिकेशन को विभिन्न ऐप स्टोर पर तैनात कर सकते हैं।
लंबी अवधि में: सर्वर अनुप्रयोगों के साथ, सुविधाओं (डीबी कनेक्शन प्रोटोकॉल और पूल, येलो पेज सिस्टम, मैसेजिंग प्रोटोकॉल और सिस्टम इत्यादि) पर किसी प्रकार की आम सहमति तक पहुंचना और उन्हें जेईई प्लेटफॉर्म जैसे कुछ मानक विनिर्देशों में पैक करना। (पिछले 20 वर्षों में बहुत सारे वैचारिक कार्य पहले ही किए जा चुके हैं)।

मुझे उम्मीद नहीं है कि आप सभी उत्तरों के साथ आएंगे! अभी जो दिमाग में आता है। Fwiw C++ में स्टैक सीमा के लिए कुछ प्रस्ताव हैं। SG14 उपसमूह देखें।

ज़रूर करूँगा।

आपके धैर्य और समय के लिए धन्यवाद।

लूटना

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

@jjpe जो एक विशेष टूलचेन (जैसे कि एमस्क्रिप्टन) के लिए एक अनुरोध होगा, जो इस रेपो के बजाय wasm को लक्षित करता है, क्योंकि यह एक टूलचैन की पसंद के कार्यान्वयन या ABI का मुद्दा है, बजाय इसके कि वेसम प्लेटफॉर्म के बारे में कुछ है। (इसलिए उदाहरण के लिए आप https://github.com/kripken/emscripten/ पर कोई समस्या खोल सकते हैं)

कुछ चीजें जो मैंने अपने पूर्व संदेश में प्रस्तावित की थीं, वे नवीनतम WASI प्रस्ताव में शामिल हैं।
देखो:
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

अंगुलियां क्रॉस करना।

--आर

FWIW वर्तमान स्थिति यह है कि क्रोम संस्करण 74 में wasm थ्रेड समर्थन शिपिंग कर रहा है, फ़ायरफ़ॉक्स में एक कार्यान्वयन है जिसे अभी तक शिप नहीं किया गया है, और Emscripten के पास pthreads समर्थन (https://emscripten.org/docs/porting/pthreads.html) है। वासम अब उपलब्ध है।

(इसके अलावा WASI एक सिस्टम कॉल एपीआई है, जो ज्यादातर ऑर्थोगोनल है कि क्या दिया गया वास्म एम्बेडिंग या टूलचेन थ्रेड्स/परमाणुओं का समर्थन करता है)।

क्या क्रोम और फ़ायरफ़ॉक्स थ्रेड एपीआई का उपयोग करने के बारे में कोई दस्तावेज़ हैं?

यह चीजों का एक संयोजन है। ब्राउज़र का wasm इंजन, wasm स्पेक (https://github.com/WebAssembly/threads/tree/master/proposals/threads) में थ्रेड्स/एटॉमिक्स एक्सटेंशन को लागू करता है, जो साझा वास्म मेमोरी को इंस्टेंट करने की अनुमति देता है। वेब पर आप एक वेब वर्कर बना सकते हैं, और पोस्टमैसेज के माध्यम से वर्कर को मेमोरी (और कोई भी संबंधित वास्म मॉड्यूल) भेज सकते हैं। फिर आप कार्यकर्ता (और मुख्य धागे, या किसी अन्य कार्यकर्ता) पर साझा स्मृति के साथ मॉड्यूल को तुरंत चालू करते हैं और उदाहरण उनकी स्मृति साझा करते हैं। विशिष्ट प्रस्ताव अवलोकन (https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md) का एक छोटा सा उदाहरण है, लेकिन मैं दूसरों के बारे में नहीं जानता।

हाय @dschuff और ऊपर दिए गए उत्तर के लिए धन्यवाद।
अपने पूर्व संदेश में मैं पिछले एक का जिक्र कर रहा था, जिसमें न केवल पर्थ्रेड शामिल थे बल्कि कुछ और कर्नेल में wasm का वांछनीय विकास शामिल था-जैसे कि हम में से कुछ लोग 2010 से emscripten का अनुसरण और उपयोग कर रहे थे, फिर एक वास्तविक सफलता तकनीक के रूप में देखा।
देखें: https://github.com/WebAssembly/design/issues/992#issuecomment -285055578।

एमस्क्रिप्टन के बाहर आने के नौ साल बाद, और वास्म घोषणाओं के लगभग पांच साल बाद, वास्म को एक व्यवहार्य सर्वर तकनीक में बदलने में बहुत कम प्रगति हुई है।

अफसोस की बात है, क्योंकि हमें पोर्टेबल ऐप्स के लिए एक मानक की आवश्यकता है, और इसे करने का सबसे अच्छा तरीका IMHO POSIX थ्रेड्स और बर्कले सॉकेट्स + एक स्व-निहित सुरक्षित वर्चुअल फाइल सिस्टम (उपयोगकर्ताओं के साथ) के साथ एक छोटे कर्नेल (बीएसडी / लिनक्स जैसे) को लागू करना होगा। और समूह पर्याप्त होंगे)। मैं एच. स्पेंसर की पुरानी कहावत पर अडिग हूं: "जो लोग यूनिक्स को नहीं समझते हैं, उन्हें इसे फिर से बनाने की निंदा की जाती है"।

मैं अब भी विश्वास बनाए रखना चाहता हूं, इसलिए WASI सही दिशा में एक कदम है।

--आर

पीएस: 2010 एमस्क्रिप्टन अभी भी चट्टानें हैं, क्योंकि यह अमर ब्राउज़र में काम करता है, अधिकांश उद्यमों में उपयोग किए जाने वाले अचूक अचूक एक और जो फ़ायरफ़ॉक्स और सफारी के निकायों (कम से कम उनके इंजन) को तैरता देखेगा।