Design: प्रस्ताव: प्रतीक्षित

को निर्मित 18 मई 2020 · 96टिप्पणियाँ · स्रोत: WebAssembly/design

@rreverser और मैं WebAssembly के लिए एक नया प्रस्ताव प्रस्तावित करना चाहता हूं: प्रतीक्षा करें।

प्रस्ताव के लिए प्रेरणा WebAssembly में संकलित " सिंक्रोनस " कोड की मदद करना है, जो फ़ाइल से पढ़ने जैसा कुछ करता है:

fread(buffer, 1, num, file);
// the data is ready to be used right here, synchronously

यह कोड आसानी से एक मेजबान वातावरण में लागू नहीं किया जा सकता है जो मुख्य रूप से एसिंक्रोनस है, और जो एसिंक्रोनस रूप से "फ़ाइल से पढ़ा" लागू करेगा, उदाहरण के लिए वेब पर,

const result = fetch("http://example.com/data.dat");
// result is a Promise; the data is not ready yet!

दूसरे शब्दों में, लक्ष्य सिंक/ एसिंक समस्या के साथ मदद करना है जो वेब पर wasm के साथ बहुत आम है।

सिंक/एसिंक समस्या एक गंभीर समस्या है। जबकि नया कोड इसे ध्यान में रखकर लिखा जा सकता है, बड़े मौजूदा कोडबेस को अक्सर इसके आसपास काम करने के लिए रिफैक्ट नहीं किया जा सकता है, जिसका अर्थ है कि वे वेब पर नहीं चल सकते हैं। हमारे पास Asyncify है जो एक wasm फ़ाइल को रोकने और फिर से शुरू करने की अनुमति देता है, और जिसने ऐसे कुछ कोडबेस को पोर्ट करने की अनुमति दी है, इसलिए हम यहां पूरी तरह से अवरुद्ध नहीं हैं। हालांकि, वास्म के उपकरण में महत्वपूर्ण ओवरहेड होता है, जैसे कोड आकार में 50% की वृद्धि और औसतन 50% मंदी (लेकिन कभी-कभी बहुत खराब), क्योंकि हम स्थानीय राज्य में वापस लिखने/पढ़ने के लिए निर्देश जोड़ते हैं और स्टैक को कॉल करते हैं और इसके आगे। वह ओवरहेड एक बड़ी सीमा है और यह कई मामलों में Asyncify को नियंत्रित करता है!

इस प्रस्ताव का लक्ष्य एक कुशल तरीके से निष्पादन को रोकने और फिर से शुरू करने की अनुमति देना है (विशेष रूप से, Asyncify जैसे ओवरहेड के बिना) ताकि सभी एप्लिकेशन जो सिंक/एसिंक्स समस्या का सामना करते हैं, वे आसानी से इससे बच सकें। व्यक्तिगत रूप से हम इसे मुख्य रूप से वेब के लिए चाहते हैं, जहां यह WebAssembly को वेब एपीआई के साथ बेहतर ढंग से एकीकृत करने में मदद कर सकता है, लेकिन वेब के बाहर के मामलों का उपयोग भी प्रासंगिक हो सकता है।

संक्षेप में विचार

यहाँ मुख्य समस्या wasm कोड के तुल्यकालिक होने और मेजबान वातावरण के बीच है जो अतुल्यकालिक है। इसलिए हमारा दृष्टिकोण एक वास उदाहरण और बाहर की सीमा पर केंद्रित है। वैचारिक रूप से, जब एक नया await निर्देश निष्पादित किया जाता है, तो wasm उदाहरण बाहर से कुछ के लिए "इंतजार" करता है। क्या "प्रतीक्षा" का अर्थ अलग-अलग प्लेटफार्मों पर अलग-अलग होगा, और सभी प्लेटफार्मों पर प्रासंगिक नहीं हो सकता है (जैसे सभी प्लेटफार्मों को वास्म परमाणु प्रस्ताव प्रासंगिक नहीं मिल सकता है), लेकिन विशेष रूप से वेब प्लेटफॉर्म पर, वासम इंस्टेंस एक वादे पर इंतजार करेगा और रुक जाएगा जब तक वह हल या अस्वीकार नहीं करता। उदाहरण के लिए, एक wasm उदाहरण fetch नेटवर्क ऑपरेशन पर रुक सकता है, और .wat में कुछ इस तरह लिखा जा सकता है:

;; call an import which returns a promise
call $do_fetch
;; wait for the promise just pushed to the stack
await
;; do stuff with the result just pushed to the stack

JS और अन्य भाषाओं में await की सामान्य समानता पर ध्यान दें। हालांकि यह उनके समान नहीं है (नीचे विवरण देखें) मुख्य लाभ यह है कि यह सिंक्रोनस-लुकिंग कोड लिखने की अनुमति देता है (या बल्कि, सिंक्रोनस-लुकिंग कोड को wasm में संकलित करने के लिए)।

विवरण

कोर वासम स्पेक

कोर wasm कल्पना में परिवर्तन बहुत कम हैं:

एक waitref प्रकार जोड़ें।
एक await निर्देश जोड़ें।

प्रत्येक await निर्देश (जैसे call_indirect ) के लिए एक प्रकार निर्दिष्ट किया गया है, उदाहरण के लिए:

;; elaborated wat from earlier, now with full types

(type $waitref_=>_i32 (func (param waitref) (result i32)))
(import "env" "do_fetch" (func $do_fetch (result waitref)))

;; call an import which returns a promise
call $do_fetch
;; wait for the promise just pushed to the stack
await (type $waitref_=>_i32)
;; do stuff with the result just pushed to the stack

प्रकार को waitref प्राप्त होना चाहिए, और किसी भी प्रकार (या कुछ भी नहीं) वापस कर सकता है।

await केवल मेजबान वातावरण को कुछ करने के संदर्भ में परिभाषित किया गया है। यह उस अर्थ में unreachable निर्देश के समान है, जो वेब पर होस्ट को RuntimeError फेंक देता है, लेकिन यह मूल कल्पना में नहीं है। इसी तरह, कोर वासम स्पेक केवल यह कहता है कि await का मतलब मेजबान वातावरण से किसी चीज की प्रतीक्षा करना है, लेकिन यह नहीं कि हम वास्तव में ऐसा कैसे करेंगे, जो विभिन्न मेजबान वातावरण में बहुत भिन्न हो सकता है।

कोर wasm कल्पना के लिए बस इतना ही!

वासम जेएस स्पेक

wasm JS spec में परिवर्तन (जो केवल वेब जैसे JS वातावरण को प्रभावित करते हैं) अधिक दिलचस्प हैं:

एक वैध waitref मान एक JS प्रॉमिस है।
जब किसी वादे पर await निष्पादित किया जाता है, तो संपूर्ण wasm उदाहरण रुक जाता है और उस वादे के हल या अस्वीकार होने की प्रतीक्षा करता है।
यदि वादा हल हो जाता है, तो वादा से प्राप्त मूल्य को स्टैक पर धकेलने के बाद इंस्टेंस निष्पादन फिर से शुरू हो जाता है (यदि कोई है)
यदि वादा अस्वीकार कर दिया जाता है, तो हम निष्पादन फिर से शुरू करते हैं और await के स्थान से एक wasm अपवाद फेंक देते हैं।

"संपूर्ण wasm उदाहरण रुक जाता है" से हमारा मतलब है कि सभी स्थानीय राज्य संरक्षित हैं (कॉल स्टैक, स्थानीय मान, आदि) ताकि हम बाद में वर्तमान निष्पादन को फिर से शुरू कर सकें, जैसे कि हम कभी नहीं रुके (बेशक वैश्विक स्थिति बदल गई हो, जैसे मेमोरी को लिखा गया होगा)। जब तक हम प्रतीक्षा करते हैं, JS ईवेंट लूप सामान्य रूप से कार्य करता है, और अन्य चीजें हो सकती हैं। जब हम बाद में फिर से शुरू करते हैं (यदि हम वादे को अस्वीकार नहीं करते हैं, तो उस स्थिति में एक अपवाद फेंक दिया जाएगा) हम ठीक उसी तरह जारी रखते हैं जहां हमने छोड़ा था, मूल रूप से जैसे कि हम कभी नहीं रुके (लेकिन इस बीच अन्य चीजें हुई हैं, और वैश्विक स्थिति हो सकती है परिवर्तित, आदि)।

यह जेएस को कैसा दिखता है जब यह एक wasm उदाहरण कहता है जो तब रुक जाता है? इसे समझाने के लिए, आइए सबसे पहले एक सामान्य उदाहरण पर एक नज़र डालें, जब मूल अनुप्रयोगों को wasm, एक ईवेंट लूप में पोर्ट किया जाता है:

void event_loop_iteration() {
  // ..
  while (auto task = getTask()) {
    task.run(); // this *may* be a network fetch
  }
  // ..
}

कल्पना कीजिए कि इस फ़ंक्शन को एक बार प्रति requestAnimationFrame कहा जाता है। यह इसे दिए गए कार्यों को निष्पादित करता है, जिसमें शामिल हो सकते हैं: रेंडरिंग, भौतिकी, ऑडियो और नेटवर्क फ़ेचिंग। यदि हमारे पास नेटवर्क लाने की घटना है, तो और केवल तभी हम await निर्देश को fetch के वादे पर चला सकते हैं। हम event_loop_iteration की एक कॉल के लिए 0 बार, या 1 बार, या कई बार ऐसा कर सकते हैं। हम केवल यह जानते हैं कि क्या हम इस wasm के निष्पादन के दौरान ऐसा करते हैं - पहले नहीं, और विशेष रूप से इस wasm निर्यात के JS कॉलर में नहीं। ताकि कॉल करने वाले को रुकने या न करने के लिए उदाहरण के लिए तैयार रहना चाहिए।

शुद्ध जावास्क्रिप्ट में कुछ इसी तरह की स्थिति हो सकती है:

function foo(bar) {
  // ..
  let result = bar(42);
  // ..
}

foo को JS फ़ंक्शन bar मिलता है और इसे कुछ डेटा के साथ कॉल करता है। जेएस में bar एक एसिंक फ़ंक्शन हो सकता है या यह सामान्य हो सकता है। यदि यह एसिंक है, तो यह एक वादा देता है, और केवल बाद में निष्पादन समाप्त करता है। यदि यह सामान्य है, तो यह लौटने से पहले निष्पादित होता है और वास्तविक परिणाम देता है। foo या तो यह मान सकता है कि यह जानता है कि किस प्रकार bar है (जेएस में कोई प्रकार नहीं लिखा गया है, वास्तव में bar एक फ़ंक्शन भी नहीं हो सकता है!), या यह संभाल सकता है दोनों प्रकार के कार्यों को पूरी तरह से सामान्य होना चाहिए।

अब, आम तौर पर आप जानते हैं कि bar किस प्रकार के कार्यों का सेट हो सकता है! उदाहरण के लिए, हो सकता है कि आपने foo और संभावित bar s को समन्वय में लिखा हो, या वास्तव में अपेक्षाओं का दस्तावेजीकरण किया हो। लेकिन जिस wasm/JS इंटरैक्शन के बारे में हम यहां बात कर रहे हैं वह वास्तव में उस मामले के समान है जहां आपके पास चीजों के बीच इतना तंग युग्मन नहीं है, और जहां वास्तव में आपको दोनों मामलों को संभालने की आवश्यकता है। जैसा कि पहले उल्लेख किया गया है, event_loop_iteration उदाहरण के लिए इसकी आवश्यकता है। लेकिन इससे भी अधिक आम तौर पर, अक्सर wasm आपका संकलित अनुप्रयोग होता है जबकि JS सामान्य "रनटाइम" कोड होता है, ताकि JS को सभी मामलों को संभालना पड़े। जेएस आसानी से ऐसा कर सकता है, उदाहरण के लिए, परिणाम की जांच करने के लिए result instanceof Promise का उपयोग करना, या जेएस await का उपयोग करना:

async function runEventLoopIteration() {
  // await in JavaScript can handle Promises as well as regular synchronous values
  // in the same way, so the log is guaranteed to be written out consistently after
  // the operation has finished (note: this handles 0 or 1 iterations, but could be
  // generalized)
  await wasm.event_loop_iteration();
  console.log("the event loop iteration is done");
}

(ध्यान दें कि यदि हमें उस console.log की आवश्यकता नहीं है तो हमें इस उदाहरण में JS await की आवश्यकता नहीं होगी, और एक wasm निर्यात के लिए केवल एक सामान्य कॉल होगी)

उपरोक्त को संक्षेप में प्रस्तुत करने के लिए, हम प्रस्ताव करते हैं कि एक रुके हुए wasm उदाहरण के व्यवहार को एक फ़ंक्शन के JS मामले पर मॉडल किया जाए जो कि async हो सकता है या नहीं भी हो सकता है, जिसे हम इस प्रकार बता सकते हैं:

जब एक await निष्पादित किया जाता है, तो wasm इंस्टेंस तुरंत वापस बाहर निकल जाता है, जिसे भी इसमें कॉल किया जाता है (आमतौर पर वह JS होगा जो wasm एक्सपोर्ट को कॉल करेगा, लेकिन बाद में नोट्स देखें)। कॉल करने वाले को एक वादा प्राप्त होता है जिसका उपयोग यह जानने के लिए किया जा सकता है कि wasm का निष्पादन कब समाप्त होता है, और यदि कोई है तो परिणाम प्राप्त करने के लिए।

टूलचेन / लाइब्रेरी सपोर्ट

Asyncify और संबंधित टूल के साथ हमारे अनुभव में यह आसान है (और मजेदार!) पहले बताए गए विकल्पों के अलावा, एक पुस्तकालय निम्नलिखित में से कोई एक कार्य कर सकता है:

अपने निर्यात को हमेशा एक वादा वापस करने के लिए एक wasm उदाहरण के चारों ओर लपेटें। यह बाहर के लिए एक अच्छा सरल इंटरफ़ेस देता है (हालांकि, यह वासम में त्वरित कॉल के लिए ओवरहेड जोड़ता है जो रुकता नहीं है)। उदाहरण के लिए, स्टैंडअलोन Asyncify हेल्पर लाइब्रेरी यही करती है।
जब कोई इंस्टेंस रुकता है तो कुछ वैश्विक स्थिति लिखें और उस जेएस से जांचें जिसने इंस्टेंस में कॉल किया था। उदाहरण के लिए, Emscripten का Asyncify एकीकरण यही करता है।

इस तरह के दृष्टिकोण, या अन्य के शीर्ष पर बहुत कुछ बनाया जा सकता है। हम प्रस्ताव और वीएम में जटिलता से बचने के लिए टूलचेन और पुस्तकालयों को छोड़ना पसंद करते हैं।

कार्यान्वयन और प्रदर्शन

कई कारकों को VM कार्यान्वयन को सरल रखने में मदद करनी चाहिए:

एक विराम/फिर से शुरू केवल एक प्रतीक्षा पर होता है, और हम प्रत्येक फ़ंक्शन के अंदर उनके स्थान को स्थिर रूप से जानते हैं।
जब हम फिर से शुरू करते हैं तो हम ठीक वहीं से चलते हैं जहां हमने चीजें छोड़ी थीं, और हम ऐसा केवल एक बार करते हैं। विशेष रूप से, हम कभी भी "कांटा" निष्पादन नहीं करते हैं: सी के setjmp या सिस्टम में एक कोरआउटिन के विपरीत, जो क्लोनिंग/फोर्किंग की अनुमति देता है, यहां कुछ भी दो बार नहीं लौटाता है।
यह स्वीकार्य है यदि await की गति जेएस को सामान्य कॉल की तुलना में धीमी है, क्योंकि हम एक वादे की प्रतीक्षा कर रहे होंगे, जिसका कम से कम मतलब है कि एक वादा आवंटित किया गया था और हम ईवेंट लूप पर प्रतीक्षा करते हैं ( जिसमें न्यूनतम ओवरहेड प्लस संभावित रूप से वर्तमान में चल रही अन्य चीजों की प्रतीक्षा कर रहा है)। यही है, यहां उपयोग के मामलों की मांग नहीं है कि वीएम कार्यान्वयनकर्ता await को तेज-तेज बनाने के तरीके ढूंढते हैं। हम केवल यहां की आवश्यकताओं की तुलना में await कुशल होना चाहते हैं, और विशेष रूप से यह उम्मीद करते हैं कि यह Asyncify के बड़े ओवरहेड से कहीं अधिक तेज़ हो।

उपरोक्त को देखते हुए, जब हम रुकते हैं तो स्टैक की प्रतिलिपि बनाना एक प्राकृतिक कार्यान्वयन है। जबकि इसमें कुछ ओवरहेड है, यहां प्रदर्शन की उम्मीदों को देखते हुए यह बहुत ही उचित होना चाहिए। और अगर हम रुकने पर ही स्टैक को कॉपी करते हैं तो हम रुकने की तैयारी के लिए अतिरिक्त काम करने से बच सकते हैं। यानी, कोई अतिरिक्त सामान्य ओवरहेड नहीं होना चाहिए (जो कि Asyncify से बहुत अलग है!)

ध्यान दें कि स्टैक की प्रतिलिपि बनाना यहां एक प्राकृतिक दृष्टिकोण है, यह पूरी तरह से छोटा ऑपरेशन नहीं है, क्योंकि वीएम के आंतरिक के आधार पर प्रतिलिपि एक साधारण यादगार नहीं हो सकती है। उदाहरण के लिए, यदि स्टैक में स्वयं के लिए पॉइंटर्स हैं, तो उन्हें या तो समायोजित करने की आवश्यकता होगी, या स्टैक को स्थानांतरित करने के लिए। वैकल्पिक रूप से, स्टैक को फिर से शुरू करने से पहले उसकी मूल स्थिति में वापस कॉपी करना संभव हो सकता है, क्योंकि जैसा कि पहले उल्लेख किया गया है, यह कभी भी "फोर्केड" नहीं होता है।

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

हम इस खंड पर VM कार्यान्वयन या प्रतिक्रिया सुनने के लिए बहुत इच्छुक हैं!

स्पष्टीकरण

यह प्रस्ताव केवल Wasm इंस्टेंस के कॉलर को WebAssembly के निष्पादन को वापस रोक देता है। यह होस्ट (JS या ब्राउज़र) स्टैक फ़्रेम को रोकने की अनुमति नहीं देता है। await एक wasm उदाहरण पर काम करता है, केवल इसके अंदर स्टैक फ्रेम को प्रभावित करता है।

एक विराम होने पर WebAssembly इंस्टेंस में कॉल करना ठीक है, और एकाधिक विराम/फिर से शुरू होने वाली घटनाएं एक साथ उड़ान में हो सकती हैं। (ध्यान दें कि यदि VM स्टैक को कॉपी करने का तरीका अपनाता है तो इसका मतलब यह नहीं है कि हर बार जब हम मॉड्यूल में प्रवेश करते हैं तो एक नया स्टैक आवंटित किया जाना चाहिए, क्योंकि हमें केवल इसे कॉपी करने की आवश्यकता होती है यदि हम वास्तव में रुकते हैं।)

अन्य प्रस्तावों से जुड़ाव

अपवाद

वादा अस्वीकृति एक अपवाद फेंकने का मतलब है कि यह प्रस्ताव wasm अपवाद प्रस्ताव पर निर्भर करता है।

कोरटाइन्स

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

विशेष रूप से, coroutines प्रस्ताव एक स्पष्ट तरीके से स्टैक निर्माण को संभालता है (एक coroutine बनाने के लिए निर्देश दिए गए हैं, एक को रोकने के लिए, आदि)। प्रतीक्षित प्रस्ताव केवल रुकने और फिर से शुरू करने की बात करता है और इसलिए स्टैक हैंडलिंग निहित है। स्पष्ट स्टैक हैंडलिंग उपयुक्त है जब आप जानते हैं कि आप विशिष्ट कोरआउट बना रहे हैं, जबकि निहित उपयुक्त है जब आप केवल जानते हैं कि आपको निष्पादन के दौरान कुछ प्रतीक्षा करने की आवश्यकता है (पहले से उदाहरण देखें event_loop_iteration )।

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

एक और महत्वपूर्ण अंतर यह है कि await एक एकल निर्देश है जो वेब के साथ सिंक/एसिंक मिसमैच वासम को ठीक करने के लिए सभी वास्म मॉड्यूल की जरूरतें प्रदान करता है (पहले .wat उदाहरण देखें। शुरुआत)। जेएस पक्ष पर उपयोग करना भी बहुत आसान है जो केवल एक वादा प्रदान कर सकता है और/या प्राप्त कर सकता है (जबकि थोड़ा पुस्तकालय कोड जोड़ने के लिए उपयोगी हो सकता है, जैसा कि पहले उल्लेख किया गया है, यह बहुत कम हो सकता है)।

सिद्धांत रूप में दो प्रस्तावों को पूरक होने के लिए डिज़ाइन किया जा सकता है। शायद await कोरआउट्स प्रस्ताव में किसी तरह के निर्देशों में से एक हो सकता है? एक अन्य विकल्प await को कोरआउटिन पर संचालित करने की अनुमति देना है (मूल रूप से एक wasm इंस्टेंस को coroutine परिणामों पर प्रतीक्षा करने का एक आसान तरीका देना)।

WASI#276

संयोग से WASI #276 @tqchen द्वारा पोस्ट किया गया था जैसे हम इसे लिखने के लिए समाप्त कर रहे थे। हमें यह देखकर बहुत खुशी हुई क्योंकि यह हमारे विश्वास को साझा करता है कि कोरआउट और एसिंक समर्थन अलग-अलग कार्यात्मकताएं हैं।

हम मानते हैं कि एक await निर्देश वहां प्रस्तावित कुछ समान (विकल्प C3) को लागू करने में मदद कर सकता है, इस अंतर के साथ कि विशेष async syscalls होने की आवश्यकता नहीं होगी, बल्कि कुछ syscalls waitref वापस कर सकते हैं await -ed हो सकता है।

जावास्क्रिप्ट के लिए हमने प्रतीक्षा को एक wasm उदाहरण को रोकने के रूप में परिभाषित किया है, जो समझ में आता है क्योंकि हमारे पास पृष्ठ पर जावास्क्रिप्ट के साथ-साथ कई उदाहरण भी हो सकते हैं। हालाँकि, कुछ सर्वर परिवेशों में केवल होस्ट और एक ही wasm उदाहरण हो सकता है, और उस स्थिति में, प्रतीक्षा करना बहुत सरल हो सकता है, शायद सचमुच फ़ाइल डिस्क्रिप्टर या GPU पर प्रतीक्षा कर रहा है। या प्रतीक्षा पूरे wasm VM को रोक सकती है लेकिन एक ईवेंट लूप चलाना जारी रख सकती है। यहां हमारे पास विशिष्ट विचार नहीं हैं, लेकिन उस मुद्दे पर चर्चा के आधार पर यहां दिलचस्प संभावनाएं हो सकती हैं, हम उत्सुक हैं कि लोग क्या सोचते हैं!

कोने का मामला: wasm उदाहरण => wasm उदाहरण => प्रतीक्षा

JS वातावरण में, जब कोई wasm इंस्टेंस रुक जाता है, तो वह तुरंत कॉल करने वाले के पास वापस आ जाता है। हमने वर्णन किया कि क्या होता है यदि कॉलर JS से है, और वही होता है यदि कॉलर ब्राउज़र है (उदाहरण के लिए, यदि हमने एक wasm निर्यात पर setTimeout किया है जो रुक जाता है; लेकिन वहां कुछ भी दिलचस्प नहीं होता है, जैसे लौटा हुआ वादा सिर्फ अनदेखा किया जाता है)। लेकिन एक और मामला है, wasm से आने वाली कॉल का, वह है, जहां wasm उदाहरण A सीधे उदाहरण से निर्यात कॉल करता है B , और B रुक जाता है। विराम हमें तुरंत B से बाहर कर देता है और एक Promise लौटा देता है।

जब कॉलर जावास्क्रिप्ट है, एक गतिशील भाषा के रूप में यह एक समस्या से कम है, और वास्तव में यह अपेक्षा करना उचित है कि कॉलर पहले चर्चा किए गए प्रकार की जांच करे। जब कॉलर WebAssembly है, जो स्थिर रूप से टाइप किया गया है, तो यह अजीब है। यदि हम इसके लिए प्रस्ताव में कुछ नहीं करते हैं, तो मूल्य को हमारे उदाहरण में एक प्रॉमिस से किसी भी उदाहरण A की अपेक्षा के अनुसार डाला जाएगा (यदि कोई i32 है, तो इसे कास्ट किया जाएगा एक 0 )। इसके बजाय, हम सुझाव देते हैं कि एक त्रुटि हो:

यदि एक wasm इंस्टेंस कॉल (सीधे या call_indirect का उपयोग करके) किसी अन्य wasm इंस्टेंस से एक फ़ंक्शन को कॉल करता है, और दूसरे इंस्टेंस में चलते समय await निष्पादित होता है, तो एक RuntimeError अपवाद है await के स्थान से फेंका गया।

महत्वपूर्ण बात यह है कि यह बिना किसी ओवरहेड के किया जा सकता है जब तक कि रुका न जाए, यानी सामान्य wasm instance -> wasm instance कॉल को पूरी गति से रखते हुए, केवल एक ठहराव करते समय स्टैक की जांच करके।

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

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

एक अन्य विकल्प यह हो सकता है कि कुछ wasm निर्यात को async के रूप में चिह्नित किया जाए जबकि अन्य को नहीं, और फिर हम सांख्यिकीय रूप से जान सकते हैं कि क्या है, और अनुचित कॉल की अनुमति नहीं है; लेकिन पहले से event_loop_iteration उदाहरण देखें जो एक सामान्य मामला है जिसे निर्यात को चिह्नित करके हल नहीं किया जाएगा, और अप्रत्यक्ष कॉल भी हैं, इसलिए हम इस तरह से इस मुद्दे से बच नहीं सकते हैं।

वैकल्पिक तरीकों पर विचार किया गया

शायद हमें एक नए await निर्देश की बिल्कुल भी आवश्यकता नहीं है, यदि जब भी कोई JS आयात एक वादा लौटाता है तो wasm रुक जाता है? समस्या यह है कि अभी जब JS एक वादा लौटाता है जो कोई त्रुटि नहीं है। इस तरह के पिछड़े-असंगत परिवर्तन का मतलब होगा कि वासम अब बिना रुके एक वादा प्राप्त नहीं कर सकता है, लेकिन यह उपयोगी भी हो सकता है।

एक अन्य विकल्प जिस पर हमने विचार किया, वह यह है कि किसी भी तरह से आयात को यह कहने के लिए चिह्नित किया जाए कि "यदि यह एक वादा लौटाता है तो यह आयात रुक जाना चाहिए"। हमने विभिन्न विकल्पों के बारे में सोचा कि उन्हें कैसे चिह्नित किया जाए, या तो JS या वासम पक्ष पर, लेकिन ऐसा कुछ भी नहीं मिला जो सही लगे। उदाहरण के लिए, यदि हम JS पक्ष पर आयात को चिह्नित करते हैं, तो wasm मॉड्यूल को यह पता नहीं चलेगा कि आयात के लिए कॉल रुकती है या नहीं, जब तक कि लिंक चरण, आयात आने पर नहीं आता है। यही है, आयात और ठहराव के लिए कॉल "एक साथ मिश्रित" होंगे। ऐसा लगता है कि सबसे सीधी बात यह है कि इसके लिए एक नया निर्देश है, await , जो प्रतीक्षा के बारे में स्पष्ट है। सिद्धांत रूप में ऐसी क्षमता वेब के बाहर भी उपयोगी हो सकती है (पहले नोट्स देखें), इसलिए सभी के लिए एक निर्देश होने से चीजें समग्र रूप से अधिक सुसंगत हो सकती हैं।

पिछली संबंधित चर्चा

https://github.com/WebAssembly/design/issues/1171
https://github.com/WebAssembly/design/issues/1252
https://github.com/WebAssembly/design/issues/1294
https://github.com/WebAssembly/design/issues/1321

पढ़ने के लिए धन्यवाद, प्रतिक्रिया का स्वागत है!

स्रोत

kripken

👍7 👀4 🚀3 🎉3 😄3 ❤2

सबसे उपयोगी टिप्पणी

मैं यहां सार्वजनिक रूप से और अधिक चर्चा करने की उम्मीद कर रहा था, लेकिन समय बचाने के लिए मैं सीधे कुछ वीएम कार्यान्वयनकर्ताओं के पास पहुंचा, क्योंकि कुछ ने अब तक यहां काम किया है। यहां चर्चा के साथ-साथ उनकी प्रतिक्रिया को देखते हुए, दुख की बात है कि मुझे लगता है कि हमें इस प्रस्ताव को रोक देना चाहिए।

सामान्य कोरआउट या स्टैक स्विचिंग की तुलना में प्रतीक्षा में बहुत सरल अवलोकन योग्य व्यवहार है, लेकिन जिन वीएम लोगों से मैंने बात की, वे @rossberg से सहमत थे कि अंत में वीएम काम शायद दोनों के लिए समान होगा। और कम से कम कुछ वीएम लोगों का मानना है कि हम किसी भी तरह से कोरआउट या स्टैक स्विचिंग प्राप्त करेंगे, और हम इसका उपयोग करके प्रतीक्षा के उपयोग के मामलों का समर्थन कर सकते हैं। इसका मतलब होगा कि प्रत्येक कॉल पर wasm (इस प्रस्ताव के विपरीत) पर एक नया कोरआउट/स्टैक बनाना, लेकिन कम से कम कुछ वीएम लोग सोचते हैं कि इसे काफी तेजी से बनाया जा सकता है।

वीएम लोगों से रुचि की कमी के अलावा, हमें इस प्रस्ताव पर @fgmccabe और @RossTate से कुछ कड़ी आपत्तियां मिली हैं, जैसा कि ऊपर चर्चा की गई है। हम कुछ बातों पर असहमत हैं लेकिन मैं उन दृष्टिकोणों और उन्हें समझाने में लगने वाले समय की सराहना करता हूं।

अंत में, कुल मिलाकर ऐसा लगता है कि यहां आगे बढ़ने की कोशिश करना सभी के समय की बर्बादी होगी। लेकिन चर्चा में भाग लेने वाले सभी लोगों को धन्यवाद! और उम्मीद है कि कम से कम यह कोरटाइन/स्टैक स्विचिंग को प्राथमिकता देने के लिए प्रेरित करता है।

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

kripken 3 जून 2020

👍7 ❤4

सभी 96 टिप्पणियाँ

बेहतरीन लेखन! मुझे मेजबान-नियंत्रित निलंबन का विचार पसंद है। @rossberg का प्रस्ताव कार्यात्मक प्रभाव प्रणालियों पर भी चर्चा करता है, और मैं निश्चित रूप से उनके साथ एक विशेषज्ञ नहीं हूं, लेकिन पहली नज़र में ऐसा लगता है कि वे समान गैर-स्थानीय नियंत्रण प्रवाह की आवश्यकता को पूरा कर सकते हैं।

devsnek 18 मई 2020

के बारे में: "उपरोक्त को देखते हुए, जब हम रुकते हैं तो स्टैक की प्रतिलिपि बनाना एक प्राकृतिक कार्यान्वयन है।" यह निष्पादन स्टैक के लिए कैसे काम करेगा? मुझे लगता है कि अधिकांश JIT इंजन JS और wasm के बीच मूल C निष्पादन स्टैक साझा करते हैं, इसलिए मुझे यकीन नहीं है कि इस संदर्भ में बचत और पुनर्स्थापना का क्या अर्थ होगा। क्या इस प्रस्ताव का मतलब यह है कि wasm निष्पादन स्टैक को किसी तरह वर्चुअलाइज्ड करने की आवश्यकता होगी? आईआईयूसी इस तरह सी स्टैक के उपयोग से बचना बहुत मुश्किल था जब अजगर ने कुछ ऐसा ही करने की कोशिश की: https://github.com/stackless-dev/stackless/wiki ।

sbc100 18 मई 2020

मैं इसी तरह की चिंता @sbc100 से साझा करता हूं। स्टैक को कॉपी करना स्वाभाविक रूप से काफी कठिन ऑपरेशन है, खासकर यदि आपके VM में पहले से GC कार्यान्वयन नहीं है।

lachlansneff 18 मई 2020

@sbc100

क्या इस प्रस्ताव का मतलब यह है कि wasm निष्पादन स्टैक को किसी तरह वर्चुअलाइज्ड करने की आवश्यकता होगी?

मुझे इसे वीएम कार्यान्वयनकर्ताओं पर छोड़ना होगा क्योंकि मैं इसका विशेषज्ञ नहीं हूं। और मैं स्टैकलेस अजगर के कनेक्शन को नहीं समझता, लेकिन शायद मुझे नहीं पता कि कनेक्शन को समझने के लिए यह पर्याप्त है, क्षमा करें!

लेकिन सामान्य तौर पर: विभिन्न कोरआउट दृष्टिकोण स्टैक पॉइंटर को निम्न स्तर पर जोड़कर काम करते हैं। वे दृष्टिकोण यहां एक विकल्प हो सकते हैं। हम यह बताना चाहते थे कि भले ही स्टैक को इस तरह के दृष्टिकोण के हिस्से के रूप में कॉपी करना पड़े, ऐसा करने से इस संदर्भ में स्वीकार्य ओवरहेड है।

(हम निश्चित नहीं हैं कि वे दृष्टिकोण wasm VMs में काम कर सकते हैं या नहीं - कार्यान्वयनकर्ताओं से सुनने की उम्मीद है कि हाँ या नहीं, और क्या बेहतर विकल्प हैं!)

@lachlansneff

क्या आप कृपया अधिक विस्तार से बता सकते हैं कि जीसी द्वारा चीजों को आसान बनाने से आपका क्या मतलब है? मैं अनुसरण नहीं करता।

kripken 18 मई 2020

@kripken GCs में अक्सर (लेकिन हमेशा नहीं) एक स्टैक पर चलने की क्षमता होती है, जो कि नए स्टैक को इंगित करने के लिए स्टैक पर पॉइंटर्स को फिर से लिखने की आवश्यकता होने पर आवश्यक है। शायद कोई व्यक्ति जो JSC के बारे में अधिक जानता है वह इसकी पुष्टि या खंडन कर सकता है।

lachlansneff 18 मई 2020

@lachlansneff

धन्यवाद, अब मैं देख रहा हूँ कि आप क्या कह रहे हैं।

हम यह सुझाव नहीं देते हैं कि ऐसा करने के लिए ढेर को पूरी तरह से चलना (प्रत्येक स्थानीय को सभी तरह से पहचानना, आदि) आवश्यक है। (अन्य संभावित दृष्टिकोणों के लिए, निम्न-स्तरीय कोरआउट कार्यान्वयन विधियों के बारे में मेरी अंतिम टिप्पणी में लिंक देखें।)

प्रस्ताव में "कॉपी द स्टैक" की शब्दावली के लिए मैं क्षमा चाहता हूं - मैं देखता हूं कि यह आपके और @ sbc100 की प्रतिक्रिया के आधार पर पर्याप्त स्पष्ट नहीं था। फिर से, हम एक विशिष्ट VM कार्यान्वयन दृष्टिकोण का सुझाव नहीं देना चाहते हैं। हम केवल यह कहना चाहते थे कि यदि किसी दृष्टिकोण में स्टैक की प्रतिलिपि बनाना आवश्यक है, तो यह गति के लिए कोई समस्या नहीं होगी।

एक विशिष्ट कार्यान्वयन दृष्टिकोण का सुझाव देने के बजाय, हम वीएम लोगों से सुनने की उम्मीद करते हैं कि वे कैसे सोचते हैं कि यह किया जा सकता है!

kripken 18 मई 2020

👍2

मैं इस प्रस्ताव को देखकर बहुत उत्साहित हूं। ल्यूसेट के पास कुछ समय के yield और resume ऑपरेटर हैं, और हम रस्ट होस्ट वातावरण में चल रहे async कोड के साथ इंटरैक्ट करने के लिए उनका सटीक उपयोग करते हैं।

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

acfoltzer 18 मई 2020

👍2

यह प्रस्ताव बहुत अच्छा लगता है! हम थोड़ी देर के लिए wasmer-js पर async कोड को प्रबंधित करने के लिए एक अच्छे तरीके से आने की कोशिश कर रहे हैं (चूंकि हमारे पास ब्राउज़र संदर्भ में VM इंटर्नल तक कोई पहुंच नहीं है)।

एक विशिष्ट कार्यान्वयन दृष्टिकोण का सुझाव देने के बजाय, हम वीएम लोगों से सुनने की उम्मीद करते हैं कि वे कैसे सोचते हैं कि यह किया जा सकता है!

मुझे लगता है कि शायद async फ़ंक्शंस के लिए कॉलबैक रणनीति का उपयोग करना चीजों को लुढ़कने का सबसे आसान तरीका हो सकता है और भाषा-अज्ञेय तरीके से भी।

syrusakbary 18 मई 2020

ऐसा लगता है कि .await को JsPromise में रस्ट फ़ंक्शन के अंदर wasm-bindgen-futures का उपयोग करके कॉल किया जा सकता है? यहां प्रस्तावित await निर्देश के बिना यह कैसे काम कर सकता है? मुझे अपनी अज्ञानता के लिए खेद है, मैं wasm के अंदर लाने के लिए समाधान ढूंढ रहा हूं और मैं Asyncify के बारे में सीख रहा हूं, लेकिन यह स्पष्ट है कि जंग समाधान सरल है। मैं यहाँ क्या खो रहा हूँ? क्या कोई मेरे लिए इसे स्पष्ट कर सकता है?

malbarbo 18 मई 2020

मैं इस प्रस्ताव को लेकर बहुत उत्साहित हूं। प्रस्ताव का मुख्य लाभ इसकी सादगी है, क्योंकि हम एपीआई का निर्माण कर सकते हैं जो वासम के पीओवी के साथ सिंक्रनाइज़ होते हैं, और यह कॉलबैक और एसिंक/प्रतीक्षा के बारे में स्पष्ट रूप से सोचने के बिना अनुप्रयोगों को पोर्ट करना बहुत आसान बनाता है। यह हमें WASM और WebGPU आधारित मशीन लर्निंग को एक ही देशी API का उपयोग करके देशी wasm vms में लाने और वेब और देशी दोनों पर चलाने में सक्षम करेगा।

tqchen 19 मई 2020

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

int test() {
   await();
   return 1;
}

संबंधित फ़ंक्शन का हस्ताक्षर () => i32 है। नए प्रस्ताव के तहत, कॉल इन टेस्ट या तो i32 लौटा सकता है, या एक Promise<i32> । ध्यान दें कि उपयोगकर्ता को एक नया हस्ताक्षर स्थिर रूप से घोषित करने के लिए कहना कठिन है (क्योंकि कोड-पोर्टिंग की लागत, और फ़ंक्शन के अंदर अप्रत्यक्ष कॉल हो सकती है जिसे हम नहीं जानते हैं कि कॉल प्रतीक्षा है)।

क्या हमारे पास निर्यात किए गए फ़ंक्शन (जैसे async कॉल) में एक अलग कॉल मोड होना चाहिए ताकि यह इंगित किया जा सके कि रनटाइम के दौरान प्रतीक्षा की अनुमति है?

शब्दावली के अनुसार, प्रस्तावित ऑपरेशन ऑपरेशन सिस्टम में यील्ड ऑपरेशन की तरह है। चूंकि यह ओएस (इस मामले में wasm VM) को syscall से finsih तक प्रतीक्षा करने के लिए नियंत्रण देता है।

tqchen 19 मई 2020

अगर मैं इस प्रस्ताव को सही ढंग से समझता हूं, तो मुझे लगता है कि यह प्रतिबंध हटाने के लगभग बराबर है कि जेएस में await केवल async कार्यों में प्रयोग योग्य हो। यही है, ततैया की तरफ waitref externref #$ हो सकता है और await निर्देश के बजाय आपके पास एक आयातित फ़ंक्शन हो सकता है $await : [externref] -> [] , और जेएस पक्ष पर आप आयात करने के लिए फ़ंक्शन के रूप में foo(promise) => await promise की आपूर्ति कर सकते हैं। दूसरी दिशा में, यदि आप जेएस कोड थे जो await async फ़ंक्शन के बाहर एक वादे पर चाहते थे, तो आप उस वादे को एक wasm मॉड्यूल को आपूर्ति कर सकते हैं जो केवल await को कॉल करता है इनपुट पर। क्या यह सही समझ है?

RossTate 19 मई 2020

@RossTate बिल्कुल नहीं, AIUI। wasm कोड await एक वादा कर सकता है (इसे promise1 कहते हैं), लेकिन केवल wasm निष्पादन ही उपज देगा, JS नहीं। wasm कोड JS कॉलर को एक अलग वादा (इसे promise2 कहते हैं) लौटाएगा। जब promise1 समाधान हो जाता है, तब wasm निष्पादन जारी रहता है। अंत में, जब वह wasm कोड सामान्य रूप से बाहर निकलता है, तो promise2 wasm फ़ंक्शन के परिणाम के साथ हल हो जाएगा।

binji 19 मई 2020

👍3

@tqchen

क्या हमारे पास निर्यात किए गए फ़ंक्शन (जैसे async कॉल) में एक अलग कॉल मोड होना चाहिए ताकि यह इंगित किया जा सके कि रनटाइम के दौरान प्रतीक्षा की अनुमति है?

दिलचस्प - आप लाभ कहाँ देखते हैं? जैसा कि आपने कहा, वास्तव में यह सुनिश्चित करने का कोई तरीका नहीं है कि निर्यात सामान्य पोर्टिंग स्थितियों में await कर रहा है या नहीं, इसलिए सर्वोत्तम रूप से इसका उपयोग कभी-कभी ही किया जा सकता है। क्या यह वीएम को आंतरिक रूप से मदद करेगा, हालांकि हो सकता है?

kripken 19 मई 2020

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

उपयोगकर्ता के पीओवी से यह कोड लेखन को और अधिक सुसंगत बनाता है। उदाहरण के लिए, उपयोगकर्ता निम्न कोड लिख सकता है, भले ही परीक्षण प्रतीक्षा को कॉल न करे, और सिस्टम इंटरफ़ेस स्वचालित रूप से Promise.resolve(test()) लौटाता है।

await inst.exports_async.test();

tqchen 19 मई 2020

ऐसा लगता है कि .await को JsPromise में रस्ट फ़ंक्शन के अंदर wasm-bindgen-futures का उपयोग करके कॉल किया जा सकता है ? await निर्देश के बिना यह कैसे काम कर सकता है? मुझे अपनी अज्ञानता के लिए खेद है, मैं wasm के अंदर लाने के लिए समाधान ढूंढ रहा हूं और मैं Asyncify के बारे में सीख रहा हूं, लेकिन यह स्पष्ट है कि जंग समाधान आसान है। क्या कोई मेरे लिए इसे स्पष्ट कर सकता है?

@malbarbo समान उपयोग के मामलों के बावजूद दो के बीच थोड़ा ओवरलैप है; रस्ट जो कर रहा है वह अनिवार्य रूप से पूर्ण कोरआउट है, जो अन्य जुड़े प्रस्तावों के दायरे में अधिक है।

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

इसके बजाय यह प्रस्ताव जो हासिल करने की कोशिश कर रहा है, वह मेजबान द्वारा प्रदान किए गए syscalls की प्रतीक्षा करने का एक तरीका है, जहां उन्हें async होना केवल एक कार्यान्वयन विवरण है, और इसलिए ऐसे कार्यों को मौजूदा कोडबेस में कहीं से भी पीछे-संगत तरीके से कॉल किया जा सकता है, बिना फिर से लिखना होगा कि पूरा ऐप कैसे संचालित होता है। (उदाहरण फ़ाइल I/O है, सी/सी++/रस्ट सहित कौन सी स्रोत भाषाएं सामान्य रूप से समकालिक रूप से उपलब्ध होने की उम्मीद करती हैं, लेकिन यह वेब पर नहीं है।)

RReverser 19 मई 2020

👍2

उपयोगकर्ता के पीओवी से यह कोड लेखन को और अधिक सुसंगत बनाता है। उदाहरण के लिए, उपयोगकर्ता निम्न कोड लिख सकता है, भले ही परीक्षण प्रतीक्षा को कॉल न करे, और सिस्टम इंटरफ़ेस स्वचालित रूप से Promise.resolve(test()) लौटाता है।

@tqchen ध्यान दें कि उपयोगकर्ता पहले से ही ऐसा कर सकता है जैसा कि प्रस्ताव परीक्षण में उदाहरण में दिखाया गया है। यानी, जावास्क्रिप्ट पहले से ही await ऑपरेटर में एक ही फैशन में सिंक्रोनस और एसिंक्रोनस दोनों मानों का समर्थन और प्रबंधन करता है।

यदि सुझाव एक स्थिर प्रकार को लागू करने का है, तो हमारा मानना है कि यह मुख्य WebAssembly पक्ष पर जटिलता को पेश किए बिना या ऐसे रैपर के कार्यान्वयनकर्ताओं को प्रतिबंधित किए बिना या तो लिंट या टाइप सिस्टम स्तर या जावास्क्रिप्ट रैपर स्तर पर किया जा सकता है।

RReverser 19 मई 2020

आह, सुधार के लिए धन्यवाद, @binji।

उस मामले में, निम्नलिखित मोटे तौर पर समकक्ष है? JS API में WebAssembly.instantiateAsync(moduleBytes, imports, "name1", "name2") फ़ंक्शन जोड़ें। मान लीजिए moduleBytes में कई आयात और अतिरिक्त आयात import "name1" "name2" (func (param externref)) है। फिर यह फ़ंक्शन imports द्वारा दिए गए मानों के साथ आयात को तत्काल करता है और अवधारणात्मक रूप से await के साथ अतिरिक्त आयात को तुरंत चालू करता है। जब इस मॉड्यूल से निर्यात किए गए फ़ंक्शन बनाए जाते हैं, तो वे सुरक्षित हो जाते हैं ताकि जब इसे await कहा जाता है तो यह पहले गार्ड को खोजने के लिए स्टैक पर चलता है और फिर स्टैक की सामग्री को एक नए वादे में कॉपी करता है जो तब होता है तुरंत वापस आ गया।

क्या इससे काम हो जायेगा? मेरा विचार यह है कि यह प्रस्ताव पूरी तरह से JS API को संशोधित करके किया जा सकता है बिना WebAssembly को संशोधित करने की आवश्यकता के। बेशक, फिर भी यह अभी भी बहुत उपयोगी कार्यक्षमता जोड़ता है।

RossTate 19 मई 2020

@kripken start फ़ंक्शन को कैसे हैंडल किया जाएगा? क्या यह स्थिर रूप से await की अनुमति नहीं देगा, या यह किसी भी तरह Wasm तत्कालता के साथ बातचीत करेगा?

@malbarbo wasm-bindgen-futures आपको रस्ट में async कोड चलाने की अनुमति देता है। इसका मतलब है कि आपको अपना प्रोग्राम एसिंक तरीके से लिखना होगा: आपको अपने कार्यों को async के रूप में चिह्नित करना होगा, और आपको .await का उपयोग करने की आवश्यकता है। लेकिन यह प्रस्ताव आपको async या .await का उपयोग किए बिना एसिंक कोड चलाने की अनुमति देता है, इसके बजाय यह एक नियमित सिंक्रोनस फ़ंक्शन कॉल की तरह दिखता है।

दूसरे शब्दों में, आप वर्तमान में सिंक्रोनस OS API (जैसे std::fs ) का उपयोग नहीं कर सकते क्योंकि वेब में केवल async API हैं। लेकिन इस प्रस्ताव के साथ आप सिंक्रोनस ओएस एपीआई का उपयोग कर सकते हैं: वे आंतरिक रूप से वादे का उपयोग करेंगे, लेकिन वे जंग के लिए तुल्यकालिक दिखेंगे ।

भले ही यह प्रस्ताव लागू हो, wasm-bindgen-futures अभी भी मौजूद रहेगा और अभी भी उपयोगी होगा, क्योंकि यह एक अलग उपयोग के मामले को संभाल रहा है ( async फ़ंक्शन चला रहा है)। और async फ़ंक्शन उपयोगी हैं क्योंकि उन्हें आसानी से समानांतर किया जा सकता है।

Pauan 19 मई 2020

👍3

@RossTate ऐसा लगता है कि आपका सुझाव "वैकल्पिक दृष्टिकोणों पर विचार" में शामिल एक के समान है:

एक अन्य विकल्प जिस पर हमने विचार किया, वह यह है कि किसी भी तरह से आयात को यह कहने के लिए चिह्नित किया जाए कि "यदि यह एक वादा लौटाता है तो यह आयात रुक जाना चाहिए"। हमने विभिन्न विकल्पों के बारे में सोचा कि उन्हें कैसे चिह्नित किया जाए, या तो JS या वासम पक्ष पर, लेकिन ऐसा कुछ भी नहीं मिला जो सही लगे। उदाहरण के लिए, यदि हम JS पक्ष पर आयात को चिह्नित करते हैं, तो wasm मॉड्यूल को यह पता नहीं चलेगा कि आयात के लिए कॉल रुकती है या नहीं, जब तक कि लिंक चरण, आयात आने पर नहीं आता है। यही है, आयात और ठहराव के लिए कॉल "एक साथ मिश्रित" होंगे। ऐसा लगता है कि सबसे सीधी बात यह है कि इसके लिए बस एक नया निर्देश है, प्रतीक्षा करें, जो प्रतीक्षा के बारे में स्पष्ट है। सिद्धांत रूप में ऐसी क्षमता वेब के बाहर भी उपयोगी हो सकती है (पहले नोट्स देखें), इसलिए सभी के लिए एक निर्देश होने से चीजें समग्र रूप से अधिक सुसंगत हो सकती हैं।

RReverser 19 मई 2020

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

@Pauan हमने इसे विशेष रूप से कवर नहीं किया है, लेकिन मुझे लगता है कि await को start में भी अनुमति देने से हमें कोई रोक नहीं सकता है। इस मामले में instantiate{Streaming} से लौटाया गया वादा तब भी स्वाभाविक रूप से हल/अस्वीकार करेगा जब स्टार्ट फ़ंक्शन पूरी तरह से निष्पादित हो गया है, केवल अंतर यह है कि यह await एड वादे की प्रतीक्षा करेगा।

उस ने कहा, आज की तरह ही सीमाएं लागू होती हैं और अभी के लिए यह उन मामलों के लिए बहुत उपयोगी नहीं होगा जिनके लिए निर्यात की गई स्मृति तक पहुंच की आवश्यकता होती है।

RReverser 19 मई 2020

@RReverser यह सिंक्रोनस new WebAssembly.Instance (जो श्रमिकों में उपयोग किया जाता है) के लिए कैसे काम करेगा?

Pauan 19 मई 2020

दिलचस्प बिंदु @Pauan शुरुआत के बारे में!

हाँ, सिंक्रोनस इंस्टेंटेशन के लिए यह जोखिम भरा लगता है - अगर await की अनुमति है, तो यह अजीब है अगर कोई रुके हुए निर्यात में कॉल करता है। await अस्वीकार करना सबसे आसान और सुरक्षित हो सकता है। (शायद स्थिरता के लिए एसिंक स्टार्ट में भी, महत्वपूर्ण उपयोग के मामले प्रतीत नहीं होते हैं जो रोकेंगे? अधिक विचार की आवश्यकता है।)

kripken 19 मई 2020

(जो श्रमिकों में प्रयोग किया जाता है)?

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

मैं सहमत हूं कि इसे start (ट्रैपिंग के रूप में) में अस्वीकार करना अभी के लिए सबसे सुरक्षित है, और हम हमेशा इसे बदल सकते हैं कि भविष्य में पीछे-संगत तरीके से कुछ बदलना चाहिए।

RReverser 19 मई 2020

👍1

हो सकता है कि मुझे कुछ याद आ गया हो, लेकिन इस बात की कोई चर्चा नहीं है कि क्या होता है जब WASM निष्पादन को await निर्देश के साथ रोक दिया जाता है और JS को एक वादा वापस कर दिया जाता है, तो JS वादे की प्रतीक्षा किए बिना WASM में वापस कॉल करता है।

क्या यह वैध उपयोग का मामला है? यदि ऐसा है, तो यह "मुख्य लूप" अनुप्रयोगों को ब्राउज़र को मैन्युअल रूप से प्रदान किए बिना इनपुट ईवेंट प्राप्त करने की अनुमति दे सकता है। इसके बजाय वे तुरंत हल किए गए वादे की प्रतीक्षा करके वापस लौट सकते थे।

Kangz 19 मई 2020

रद्द करने के बारे में क्या? इसे जेएस वादों में लागू नहीं किया गया है और इससे कुछ समस्याएं होती हैं।

chicoxyzzy 19 मई 2020

@Kangz

हो सकता है कि मुझे कुछ याद आ गया हो, लेकिन इस बात की कोई चर्चा नहीं है कि क्या होता है जब WASM निष्पादन को प्रतीक्षा निर्देश के साथ रोक दिया जाता है और JS को एक वादा वापस कर दिया जाता है, तो JS वादे की प्रतीक्षा किए बिना WASM में वापस कॉल करता है।
क्या यह वैध उपयोग का मामला है? यदि ऐसा है, तो यह "मुख्य लूप" अनुप्रयोगों को ब्राउज़र को मैन्युअल रूप से प्रदान किए बिना इनपुट ईवेंट प्राप्त करने की अनुमति दे सकता है। इसके बजाय वे तुरंत हल किए गए वादे की प्रतीक्षा करके वापस लौट सकते थे।

वर्तमान पाठ शायद उस पर पर्याप्त स्पष्ट नहीं है। पहले पैराग्राफ के लिए, हाँ, इसकी अनुमति है, "स्पष्टीकरण" अनुभाग देखें: It is ok to call into the WebAssembly instance while a pause has occurred, and multiple pause/resume events can be in flight at once.

दूसरे पैराग्राफ के लिए, नहीं - आप पहले की घटनाओं को प्राप्त नहीं कर सकते हैं, और आप जेएस को इससे पहले एक वादा हल नहीं कर सकते हैं। मुझे चीजों को दूसरे तरीके से सारांशित करने का प्रयास करें:

जब wasm प्रॉमिस ए पर रुकता है, तो यह वापस बाहर निकल जाता है जिसे इसे कहा जाता है, और एक नया प्रॉमिस बी लौटाता है।
जब वादा A हल करता है तो Wasm फिर से शुरू हो जाता है। यह सामान्य समय पर होता है , जिसका अर्थ है कि JS ईवेंट लूप में सब कुछ सामान्य है।
वास के बाद फिर से शुरू होता है और दौड़ना भी खत्म हो जाता है, उसके बाद ही प्रॉमिस बी का समाधान होता है।

तो विशेष रूप से वादा बी को वादा ए के बाद हल करना है। आप जेएस से पहले वादा ए का परिणाम प्राप्त नहीं कर सकते हैं।

इसे दूसरे तरीके से रखने के लिए: इस प्रस्ताव के व्यवहार को Asyncify + कुछ JS द्वारा पॉलीफ़िल किया जा सकता है जो इसके चारों ओर वादों का उपयोग करते हैं।

kripken 19 मई 2020

@RReverser , मुझे नहीं लगता कि वे वही हैं, लेकिन पहले मुझे लगता है कि हमें कुछ स्पष्ट करने की आवश्यकता है (यदि इसे पहले ही स्पष्ट नहीं किया गया है, तो इस मामले में मुझे इसे याद करने के लिए खेद है)।

एक ही समय में एक ही स्टैक पर JS से एक ही wasm इंस्टेंस में कई कॉल हो सकते हैं। यदि await उदाहरण द्वारा निष्पादित हो जाता है, तो कौन सी कॉल रुक जाती है और एक वादा वापस कर देती है?

RossTate 19 मई 2020

दूसरे पैराग्राफ के लिए, नहीं - आप पहले की घटनाओं को प्राप्त नहीं कर सकते हैं, और आप जेएस को इससे पहले एक वादा हल नहीं कर सकते हैं।

क्षमा करें, मुझे लगता है कि मेरा प्रश्न स्पष्ट नहीं था। फिलहाल सी ++ में "मेन-लूप" ऐप्स emscripten_set_main_loop का उपयोग करते हैं ताकि फ्रेम फ़ंक्शन के प्रत्येक रन के बीच, ब्राउज़र पर नियंत्रण वापस मिल जाए, और इनपुट या अन्य घटनाओं को संसाधित किया जा सके।

इस प्रस्ताव के साथ, ऐसा लगता है कि निम्नलिखित को "मेन-लूप" ऐप्स का अनुवाद करने के लिए काम करना चाहिए। (हालांकि मैं जेएस इवेंट लूप को अच्छी तरह से नहीं जानता)

int main() {
  while (true) {
    frame();
    processEvents();
  }
}

// polyfillable with ASYNCIFY!
void processEvents() {
  __builtin_await(EM_ASM(
    new Promise((resolve, reject) => {
      setTimeout(0, () => resolve());
    })
  ))
}

Kangz 19 मई 2020

@ कांगज़ को काम करना चाहिए, हाँ (सिवाय इसके कि आपके सेटटाइमआउट कोड में तर्कों के क्रम के साथ एक छोटी सी समस्या है और इसे सरल बनाया जा सकता है):

int main() {
  while (true) {
    frame();
    processEvents();
  }
}

// polyfillable with ASYNCIFY!
void processEvents() {
  __builtin_await(EM_ASM_WAITREF(
    return new Promise(resolve => setTimeout(resolve));
  ));
}

RReverser 19 मई 2020

एक ही समय में एक ही स्टैक पर JS से एक ही wasm इंस्टेंस में कई कॉल हो सकते हैं। यदि इंस्टेंस द्वारा प्रतीक्षा को निष्पादित किया जाता है, तो कौन सी कॉल रुक जाती है और एक वादा वापस कर देती है?

अंतरतम वाला। अगर वह ऐसा करना चाहता है तो बाकी को समन्वयित करना जेएस रैपर का काम है।

RReverser 19 मई 2020

@ कांगज़ क्षमा करें, मैंने आपको पहले गलत समझा था। हां, जैसा कि @RReverser ने कहा था कि काम करना चाहिए, और यह यहां एक इच्छित उपयोग के मामले का एक अच्छा उदाहरण है!

जैसा कि आपने कहा था कि यह Asyncify के साथ पॉलीफ़िल करने योग्य है, और वास्तव में यह __builtin_await को emscripten_sleep(0) (जो setTimeout(0) करता है) पर कॉल के साथ बदलकर आज Asyncify के समान कोड के बराबर है। .

kripken 19 मई 2020

धन्यवाद, @RReverser , स्पष्टीकरण के लिए। मुझे लगता है कि यह कहने के लिए विवरण को फिर से परिभाषित करने में मदद करेगा कि उदाहरण के बजाय (सबसे हालिया) कॉल इंस्टेंस में रुक जाता है।

उस स्थिति में, यह जेएस में निम्नलिखित दो आदिम कार्यों को जोड़ने के लगभग बराबर लगता है: promise-on-await(f) और await-for-promise(p) । पूर्व कॉल f() लेकिन, यदि f() await-for-promise(p) कॉल किया जाता है, तो इसके बजाय एक नया वादा लौटाता है जो p हल होने के बाद निष्पादन फिर से शुरू करता है और निष्पादन पूर्ण होने के बाद स्वयं हल हो जाता है (या await-for-promise फिर से कॉल करता है)। यदि कई promise-on-await s के संदर्भ में await-for-promise पर कॉल की जाती है, तो सबसे हाल का एक वादा लौटाता है। यदि किसी await-for-promise पर कॉल किसी भी promise-on-await के बाहर की जाती है, तो कुछ बुरा होता है (जैसे कि किसी इंस्टेंस का start कोड निष्पादित होता है await )।

क्या इसका कोई मतलब है?

RossTate 19 मई 2020

@RossTate यह काफी करीब है, हां, और सामान्य विचार को पकड़ता है। (लेकिन जैसा कि आपने कहा, केवल लगभग समकक्ष, क्योंकि इसका उपयोग इसे पॉलीफिल करने के लिए नहीं किया जा सकता है, और इसमें विशिष्ट wasm/JS सीमा प्रबंधन गुम है।)

उस पाठ को फिर से लिखने के सुझाव के लिए धन्यवाद। मैं यहां चर्चा से ऐसे नोट्स की एक सूची रख रहा हूं। (मुझे यकीन नहीं है कि क्या उन्हें पहली पोस्ट पर लागू करना उचित है, क्योंकि यह समय के साथ इसे बदलने के लिए कम भ्रमित नहीं लगता है?)

kripken 19 मई 2020

@RossTate दिलचस्प... मुझे यह पसंद है! यह कॉल की एसिंक प्रकृति को स्पष्ट करता है ( promise-on-await किसी भी संभावित एसिंक कॉल के लिए आवश्यक है), और वासम में किसी भी बदलाव की आवश्यकता नहीं है। यदि आप बीच से Wasm हटाते हैं तो यह (कुछ) समझ में आता है - यदि promise-on-await await-for-promise $ पर कॉल करता है, तो यह Promise लौटाता है।

@kripken क्या आप इस बारे में अधिक विस्तार से जा सकते हैं कि यह अलग क्यों होगा? मुझे समझ में नहीं आता कि वासम/जेएस सीमा यहां क्यों मायने रखती है।

binji 19 मई 2020

@ बिनजी मेरा मतलब सिर्फ इतना था कि जेएस में इस तरह के कार्य वासम को कुछ ऐसा ही करने नहीं देंगे। उन्हें wasm से आयात के रूप में बुलाने से काम नहीं चलेगा। हमें अभी भी वासम को सीमा से बाहर निकालने आदि के लिए एक फिर से शुरू करने योग्य तरीके की आवश्यकता है, है ना?

kripken 19 मई 2020

@kripken ठीक है, मुझे लगता है कि उस समय await-for-promise आयात को Wasm आंतरिक की तरह काम करना होगा।

binji 19 मई 2020

मेरी सोच यह थी कि, wasm में await निर्देश जोड़ने के बजाय, ऐसा मॉड्यूल इसके बजाय await-for-promise आयात करेगा और उसे कॉल करेगा। इसी तरह, निर्यात किए गए कार्यों को बदलने के बजाय, जेएस कोड उन्हें promise-on-await के अंदर बुलाएगा। इसका मतलब यह है कि JS प्राइमेटिव WebAssembly स्टैक सहित सभी स्टैक कार्य को संभालेंगे। यह अधिक लचीला भी होगा, उदाहरण के लिए यदि आप चाहते हैं कि आप मॉड्यूल को एक जेएस कॉलबैक दे सकते हैं जो तब मॉड्यूल में वापस कॉल कर सकता है और आंतरिक क्लॉज के बजाय बाहरी कॉल पॉज़ कर सकता है --- यह सब इस बात पर निर्भर करता है कि जेएस कोड चुनता है या नहीं कॉल को promise-on-await में लपेटने के लिए या नहीं। मुझे नहीं लगता कि आपको वासम में कुछ भी बदलने की जरूरत है।

RossTate 19 मई 2020

मुझे यह जानने में दिलचस्पी होगी कि @syg इन संभावित जेएस प्राइमेटिव्स के बारे में क्या सोचता है।

tlively 19 मई 2020

ओह ठीक है, क्षमा करें - मैंने आपकी टिप्पणी @RossTate को "यह सुनिश्चित करने के लिए कि मैं समझता हूं, मुझे इसे इस तरह दोबारा दोहराएं, और मुझे बताएं कि इसका सही आकार है", और कोई ठोस सुझाव नहीं है।

इसके बारे में सोचकर, आपका विचार न केवल JS फ्रेम बल्कि wasm को भी रोकना चाहता है, बल्कि होस्ट/ब्राउज़र फ़्रेम भी हैं। (मौजूदा प्रस्ताव इस बात से बचा जाता है कि केवल उस सीमा तक काम करने से बचा जा सकता है जहां उसे बुलाया गया था।) यहां एक उदाहरण दिया गया है:

myList.forEach((item) => {
  .. call something which ends up pausing ..
});

यदि ब्राउज़र कोड में forEach लागू किया गया है तो इसका अर्थ है ब्राउज़र फ़्रेम को रोकना। यह भी महत्वपूर्ण है कि इस तरह के लूप के बीच में रुकना, और बाद में फिर से शुरू करना, एक नई शक्ति होगी जो जेएस कर सकता है, और आपका विचार सामान्य लूप के लिए भी अनुमति देगा:

for (let i of something) {
  .. call something which ends up pausing ..
}

और यह सब async JS फ़ंक्शंस के साथ उत्सुक विशिष्ट इंटरैक्शन हो सकता है। ये सभी ब्राउज़र और JS लोगों के साथ होने वाली बड़ी चर्चाओं की तरह प्रतीत होते हैं।

लेकिन साथ ही, यह केवल await और waitref को कोर wasm स्पेक में जोड़ने से बचाता है, लेकिन वे छोटे जोड़ हैं - क्योंकि वे कोर स्पेक में कुछ भी नहीं करते हैं। वर्तमान प्रस्ताव में पहले से ही जेएस पक्ष पर 99% जटिलता है। और IIUC आपका प्रस्ताव JS की तरफ बहुत बड़े परिवर्धन के साथ wasm कल्पना के उस छोटे से जोड़ को बंद कर देता है - इसलिए यह वेब प्लेटफॉर्म को और अधिक जटिल बना देता है, और अनावश्यक रूप से क्योंकि यह सब wasm के लिए है। साथ ही, कोर वासम स्पेक में await को परिभाषित करने का वास्तव में एक लाभ है, कि यह वेब के बाहर उपयोगी हो सकता है।

हो सकता है कि मैंने आपके सुझाव में कुछ याद किया हो, क्षमा करें यदि ऐसा है। कुल मिलाकर, मैं उत्सुक हूं कि कोर वासम स्पेक के अतिरिक्त से बचने की कोशिश करने के लिए आपकी प्रेरणा क्या है?

kripken 19 मई 2020

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

devsnek 19 मई 2020

👍1

मेरी टिप्पणी दोनों का संयोजन थी। उच्च स्तर पर, मैं यह पता लगाने की कोशिश कर रहा हूं कि प्रस्ताव को पूरी तरह से जेएस एपीआई के संवर्धन के रूप में फिर से परिभाषित करने का कोई तरीका है (और इसी तरह अन्य मेजबान वासम मॉड्यूल के साथ कैसे बातचीत करेंगे)। यह अभ्यास यह आकलन करने में मदद करता है कि क्या वास्तव में wasm को बदलने की आवश्यकता है और यह निर्धारित करने में मदद करता है कि क्या वास्तव में प्रस्ताव गुप्त रूप से JS में नए आदिम जोड़ रहा है जिसे JS लोग स्वीकार कर सकते हैं या नहीं। यही है, अगर यह सिर्फ एक आयातित await : func (param externref) (result externref) के साथ करना संभव नहीं है, तो यह काफी संभावना है कि यह जेएस में नई कार्यक्षमता जोड़ रहा है।

wasm में परिवर्तनों की सादगी के लिए, अभी भी कई बातों पर विचार करना है जैसे मॉड्यूल कॉल के लिए मॉड्यूल के बारे में क्या करना है, क्या करना है जब निर्यात किए गए फ़ंक्शन GC मान लौटाते हैं जिसमें फ़ंक्शन के लिए पॉइंटर्स होते हैं जो await निष्पादित कर सकते हैं कॉल खत्म होने के बाद, और इसी तरह।

अभ्यास पर लौटते हुए, जैसा कि आपने बताया कि केवल ततैया के ढेर को पकड़ने के अच्छे कारण हैं। यह मुझे मेरे पहले के सुझाव पर वापस लाता है, हालांकि कुछ नए परिप्रेक्ष्य के साथ थोड़ा संशोधित किया गया है। JS API में WebAssembly.instantiateAsync(moduleBytes, imports, "name1", "name2") फ़ंक्शन जोड़ें। मान लीजिए moduleBytes में कई आयात और अतिरिक्त आयात import "name1" "name2" (func (param externref) (result externref)) है। फिर instantiateAsync moduleBytes के अन्य आयातों को केवल imports द्वारा दिए गए मानों के साथ तत्काल करता है और अतिरिक्त आयात को अवधारणात्मक रूप से await-for-promise के साथ तत्काल करता है। जब इस उदाहरण से निर्यात किए गए फ़ंक्शन बनाए जाते हैं, तो वे संरक्षित हो जाते हैं (अवधारणात्मक रूप से promise-on-await ) ताकि जब इसे await-for-promise कहा जाए तो यह पहले गार्ड को खोजने के लिए स्टैक तक चलता है और फिर सामग्री की प्रतिलिपि बनाता है स्टैक ओवर एक नए प्रॉमिस में जिसे तुरंत वापस कर दिया जाता है। अब हमारे पास वही आदिम हैं जिनका मैंने ऊपर उल्लेख किया है, लेकिन वे अब प्रथम श्रेणी नहीं हैं, और यह प्रतिबंधित पैटर्न सुनिश्चित करता है कि केवल वास्म स्टैक कभी भी कब्जा कर लिया जाएगा। उसी समय, पैटर्न का समर्थन करने के लिए WebAssembly को बदलने की आवश्यकता नहीं है।

विचार?

RossTate 19 मई 2020

@devsnek

मैं अभी भी उत्सुक हूं कि क्यों पुन: प्रयोज्य अपवाद (मोटे तौर पर प्रभाव) इस उपयोग के मामले को पूरा नहीं करेंगे।

वे इस स्थान में एक विकल्प हैं, निश्चित रूप से।

@rossberg की अंतिम प्रस्तुति से मेरी समझ यह है कि वह शुरू में उस मार्ग से नीचे जाना चाहता था, लेकिन फिर एक कोरआउट दृष्टिकोण करने के लिए दिशा बदल दी। "समस्याएं" शीर्षक वाली स्लाइड देखें। उस स्लाइड के बाद, coroutines का वर्णन किया गया है, जो इस स्थान में एक और विकल्प हैं। तो हो सकता है कि आपका प्रश्न @rossberg के लिए अधिक हो जो शायद स्पष्ट कर सके?

यह प्रस्ताव सिंक / एसिंक्स समस्या को हल करने पर केंद्रित है, जिसके लिए उतनी शक्ति की आवश्यकता नहीं होती जितनी कि पुन: प्रयोज्य अपवाद या कोरआउटिन की आवश्यकता होती है। वे एक wasm मॉड्यूल के अंदर आंतरिक इंटरैक्शन पर ध्यान केंद्रित करते हैं, जबकि हम एक wasm मॉड्यूल और बाहर के बीच बातचीत पर ध्यान केंद्रित करते हैं (क्योंकि यही वह जगह है जहां सिंक / async समस्या होती है)। इसलिए हमें कोर wasm स्पेक में केवल एक नए निर्देश की आवश्यकता है, और इस प्रस्ताव में लगभग सभी तर्क wasm JS spec में हैं। और इसका मतलब है कि आप इस तरह से एक वादे की प्रतीक्षा कर सकते हैं:

call $get_promise
await
;; use it!

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

@RossTate

यही है, अगर यह केवल एक आयातित प्रतीक्षा के साथ करना संभव नहीं है: func (param externref) (परिणाम externref), तो यह काफी संभावना है कि यह जेएस में नई कार्यक्षमता जोड़ रहा है।

मैं उस अनुमान का पालन नहीं करता, क्षमा करें। लेकिन यह मुझे गोल चक्कर लगता है। अगर आपको लगता है कि यह प्रस्ताव जेएस में नई कार्यक्षमता जोड़ता है, तो इसे सीधे क्यों न दिखाएं? (मैं दृढ़ता से मानता हूं कि ऐसा नहीं होता है, लेकिन अगर आप पाते हैं कि हमने गलती की है तो मैं उत्सुक हूं!)

wasm में परिवर्तन की सादगी के लिए, अभी भी कई बातों पर विचार करना है जैसे मॉड्यूल से मॉड्यूल कॉल के बारे में क्या करना है

क्या कोर वासम स्पेक मॉड्यूल से मॉड्यूल कॉल के बारे में कुछ कहता है? मुझे ऐसा करना याद नहीं है, और प्रासंगिक अनुभागों को स्किम करना अब मुझे वह दिखाई नहीं दे रहा है। लेकिन शायद मुझे कुछ याद आया?

मेरा विश्वास यह है कि मूल wasm स्पेक जोड़ मूल रूप से await सूचीबद्ध करने के लिए होंगे, कहें कि यह "कुछ प्रतीक्षा करें" के लिए है, और यही वह है। इसलिए मैंने प्रस्ताव में That's it for the core wasm spec! लिखा। अगर मैं गलत हूं, तो कृपया मुझे कोर वासम स्पेक में दिखाएं जहां हमें और जोड़ना होगा।

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

यह मुझे मेरे पहले के सुझाव पर वापस लाता है, हालांकि कुछ नए परिप्रेक्ष्य के साथ थोड़ा संशोधित [नया विचार]

क्या यह विचार कार्यात्मक रूप से प्रस्ताव में Alternative approaches considered में दूसरे पैराग्राफ के समान नहीं है? ऐसा कुछ किया जा सकता है, लेकिन हमने समझाया कि हमें क्यों लगता है कि यह कम अच्छा है।

kripken 20 मई 2020

@kripken मिल गया। स्पष्ट होने के लिए मुझे लगता है कि await एक बहुत ही व्यावहारिक और सुरुचिपूर्ण तरीके से प्रस्तुत उपयोग के मामलों को हल करता है। मैं बस इस तरह की उम्मीद कर रहा हूं कि हम इस गति का उपयोग अन्य उपयोग के मामलों को हल करने के साथ-साथ डिजाइन को थोड़ा विस्तृत करके भी कर सकते हैं।

devsnek 20 मई 2020

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

sbc100 20 मई 2020

मुझे लगता है कि हम सभी सहमत हो सकते हैं कि एक समाधान जिसमें कोई wasm कल्पना परिवर्तन शामिल नहीं है, बेहतर होगा

नहीं! यहां चर्चा किए गए गैर-वेब उपयोग के मामलों को देखें। wasm स्पेक में await के बिना, हम प्रत्येक प्लेटफ़ॉर्म के साथ कुछ तदर्थ कर रहे होंगे: JS वातावरण कुछ आयात करता है, अन्य स्थान "सिंक्रोनस" के रूप में चिह्नित नए API बनाते हैं, आदि। wasm पारिस्थितिकी तंत्र होगा कम सुसंगत होना, वेब से अन्य स्थानों पर एक ततैया को स्थानांतरित करना कठिन होगा, आदि।

लेकिन हां, हमें कोर वासम स्पेक पार्ट को यथासंभव सरल बनाना चाहिए। मुझे लगता है कि यह करता है? 99% तर्क जेएस पक्ष पर है (लेकिन @RossTate असहमत प्रतीत होता है, और हम अभी भी इसे समझने की कोशिश कर रहे हैं - मैंने अपनी आखिरी प्रतिक्रिया में ठोस प्रश्न पूछे हैं कि मुझे उम्मीद है कि चीजें आगे बढ़ेंगी)।

kripken 20 मई 2020

👍6

मेरा विश्वास यह है कि मूल wasm स्पेक जोड़ मूल रूप से await सूचीबद्ध करने के लिए होंगे, कहें कि यह "कुछ प्रतीक्षा करें" के लिए है, और यही वह है।

जब तक इन शब्दार्थों को अधिक सटीक रूप से औपचारिक रूप नहीं दिया जा सकता है, यह अस्पष्टता या कार्यान्वयन-परिभाषित व्यवहार को कल्पना में पेश करता है। हमने अब तक इससे परहेज किया है (SIMD के मामले में महत्वपूर्ण कीमत पर), इसलिए यह निश्चित रूप से कुछ ऐसा है जिसे मैं नीचे देखना चाहता हूं। मुझे नहीं लगता कि इसे और अधिक औपचारिक बनाने के लिए प्रस्ताव को बदलना होगा, लेकिन "कुछ के लिए प्रतीक्षा करें" को पहले से ही युक्ति द्वारा उपयोग की जाने वाली सटीक शब्दावली में फिर से लिखा जाना चाहिए।

tlively 20 मई 2020

क्या कोर वासम स्पेक मॉड्यूल से मॉड्यूल कॉल के बारे में कुछ कहता है?

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

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

व्यक्तिगत बैठक में चर्चा किए गए मॉड्यूल-संरचना सिद्धांत के आधार पर, इसे फंसना नहीं चाहिए। यह ऐसा होना चाहिए जैसे कि केवल एक (रचित) मॉड्यूल उदाहरण था और इसे await निष्पादित किया गया था। अर्थात्, await स्टैक को नवीनतम JS स्टैक फ्रेम तक पैक करेगा।

ध्यान दें कि इसका तात्पर्य है कि यदि f कुछ wasm उदाहरण के निर्यात किए गए यूनरी फ़ंक्शन का मूल्य था, तो तत्काल-पैरामीटर ऑब्जेक्ट {"some" : {"import" : f}} शब्दार्थ रूप से {"some" : {"import" : (x) => f(x)}} से भिन्न होगा क्योंकि कॉल पूर्व में वास्म स्टैक के भीतर रहेगा जबकि बाद वाले को कॉल जेएस स्टैक में प्रवेश करेगा, भले ही वह मुश्किल से ही क्यों न हो। अब तक इन तात्कालिकता-पैरामीटर वस्तुओं को समकक्ष माना जाएगा। मैं इसमें जा सकता हूं कि यह कोड-माइग्रेशन/भाषा-इंटरऑप दृष्टिकोण से क्यों उपयोगी है, लेकिन इस समय यह एक विषयांतर होगा।

क्या यह विचार कार्यात्मक रूप से प्रस्ताव में विचार किए गए वैकल्पिक दृष्टिकोण के दूसरे पैराग्राफ के समान नहीं है? ऐसा कुछ किया जा सकता है, लेकिन हमने समझाया कि हमें क्यों लगता है कि यह कम अच्छा है।

क्षमा करें, मैंने उस विकल्प को कुछ अलग अर्थ के रूप में पढ़ा, लेकिन अब मेरे भ्रम की व्याख्या करने के अलावा कोई फर्क नहीं पड़ता। ऐसा लगता है कि आप मेरे सुझाव के समान ही थे, इस मामले में पेशेवरों और विपक्षों पर चर्चा करना उचित है।

तथ्य यह है कि यह प्रस्ताव वास पक्ष पर इतना हल्का है क्योंकि await निर्देश एक आयातित फ़ंक्शन के लिए कॉल के समान अर्थपूर्ण लगता है। बेशक, सम्मेलन मायने रखता है, जैसा कि आप बताते हैं! लेकिन केवल await ही कार्यक्षमता नहीं है जिसके लिए यह धारण करता है; अधिकांश आयातित कार्यों के लिए भी यही सच है। के मामले में await , मेरी समझ में यह है कि सम्मेलन के बारे में चिंता को संबोधित किया जा सकता है इस कार्यक्षमता वाले मॉड्यूल में import "control" "await" (func (param externref) (result externref)) क्लॉज है, और इस कार्यक्षमता का समर्थन करने वाले वातावरण हमेशा उस आयात को तुरंत चालू करते हैं उचित कॉलबैक के साथ।

ऐसा लगता है कि एक ऐसा समाधान प्रदान करता है जो आपके द्वारा खोजे जा रहे क्रॉस-प्लेटफ़ॉर्म पोर्टेबिलिटी प्रदान करते हुए wasm को न बदलकर एक टन काम बचाता है। लेकिन मैं अभी भी प्रस्ताव की बारीकियों को समझने के लिए काम कर रहा हूं, और मैं अब तक एक गुच्छा चूक चुका हूं!

RossTate 20 मई 2020

तथ्य यह है कि यह प्रस्ताव वास पक्ष पर इतना हल्का है क्योंकि प्रतीक्षा निर्देश एक आयातित फ़ंक्शन के कॉल के समान अर्थपूर्ण रूप से समान प्रतीत होता है।

एफडब्ल्यूआईडब्ल्यू यह वह जगह है जहां यह प्रस्ताव मूल रूप से शुरू हुआ था, लेकिन इस तरह के इंट्रिनिक्स का उपयोग वीएम के लिए अधिक अपारदर्शी लगता है और आम तौर पर निराश होता है (मुझे लगता है कि @binji ने मूल चर्चाओं में इससे दूर जाने का सुझाव दिया था)।

उदाहरण के लिए, आपके तर्क के बाद, memory.grow या atomic.wait जैसा कुछ भी import "control" "memory_grow" या import "control" "atomic_wait" के अनुरूप किया जा सकता है, लेकिन वे वैसे नहीं हैं जैसे वे करते हैं वास्तविक निर्देश के रूप में समान स्तर के इंटरऑप और स्थिर विश्लेषण अवसर (वीएम और टूलिंग दोनों तरफ) प्रदान नहीं करते हैं।

आप तर्क दे सकते हैं कि निर्देश के रूप में memory.grow अभी भी उन मामलों के लिए उपयोगी है जहां स्मृति निर्यात नहीं की जाती है, लेकिन atomic.wait निश्चित रूप से कोर के बाहर लागू किया जा सकता है। वास्तव में, यह await के समान ही है, उस स्तर को छोड़कर जिस पर विराम/फिर से शुरू होता है और इस तथ्य के लिए कि await फ़ंक्शन के रूप में atomic.wait की तुलना में अधिक जादू की आवश्यकता होगी चूंकि इसे वीएम स्टैक के साथ इंटरैक्ट करने में सक्षम होना चाहिए और न केवल वर्तमान थ्रेड को तब तक ब्लॉक करना चाहिए जब तक कि कोई मूल्य बदल न जाए।

RReverser 20 मई 2020

@tlively

"कुछ के लिए प्रतीक्षा करें" को पहले से ही युक्ति द्वारा उपयोग की जाने वाली सटीक शब्दावली में फिर से लिखा जाना चाहिए।

निश्चित रूप से हाँ। मैं अब कुछ और विशिष्ट पाठ सुझा सकता हूं यदि वह सहायक होगा:

When an await instruction is executed on a waitref, the host environment is requested to do some work. Typically there would be a natural meaning to what that work is based on what a waitref is on a specific host (in particular, waiting for some form of host event), but from the wasm module's point of view, the semantics of an await are similar to a call to an imported host function, that is: we don't know exactly what the host will do, but at least expect to give it certain types and receive certain results; after the instruction executes, global state (the store) may change; and an exception may be thrown.

The behavior of an await from the host's perspective may be very different, however, from a call to an imported host function, and might involve something like pausing and resuming the wasm module. It is for this reason that this instruction is defined. For the instruction to be usable on a particlar host, the host would need to define the proper behavior.

बीटीडब्ल्यू, एक और तुलना जो इसे लिखते समय मेरे पास आई, वह है लोड और स्टोर पर संरेखण संकेत। Wasm असंरेखित भार और भंडार का समर्थन करता है, इसलिए संकेत wasm मॉड्यूल (भले ही संकेत गलत हो) द्वारा अलग-अलग व्यवहार को देखने योग्य नहीं हो सकते हैं, लेकिन मेजबान के लिए वे कुछ प्लेटफार्मों पर एक बहुत अलग कार्यान्वयन का सुझाव देते हैं (जो अधिक कुशल हो सकता है)। तो यह आंतरिक रूप से देखने योग्य विभिन्न अर्थशास्त्र के बिना विभिन्न निर्देशों का एक उदाहरण है, जैसा कि युक्ति कहती है: The alignment in load and store instructions does not affect the semantics ।

kripken 20 मई 2020

@RossTate

व्यक्तिगत बैठक में चर्चा किए गए मॉड्यूल-संरचना सिद्धांत के आधार पर, इसे फंसना नहीं चाहिए। यह ऐसा होना चाहिए जैसे कि केवल एक (रचित) मॉड्यूल इंस्टेंस था और इसे प्रतीक्षा में निष्पादित किया गया था। यही है, प्रतीक्षित स्टैक को नवीनतम जेएस स्टैक फ्रेम तक पैक करेगा।

अच्छा लगता है, और जानना अच्छा है, धन्यवाद, मुझे वह हिस्सा याद आया।

मुझे लगता है कि यह मुझे हमारी गलतफहमी का हिस्सा समझाता है। मॉड्यूल => मॉड्यूल कॉल wasm spec atm में नहीं हैं, जो पहले मेरी बात थी। लेकिन ऐसा लगता है कि आप भविष्य की कल्पना के बारे में सोच रहे हैं जहां वे हो सकते हैं। किसी भी मामले में, यह यहां एक समस्या की तरह नहीं दिखता है, क्योंकि संरचना यह निर्धारित करती है कि उस स्थिति में प्रतीक्षा कैसे व्यवहार करना चाहिए (जो मैंने पहले सुझाव नहीं दिया था! लेकिन अधिक समझ में आता है)।

kripken 20 मई 2020

क्या कोर वासम स्पेक मॉड्यूल से मॉड्यूल कॉल के बारे में कुछ कहता है? मुझे ऐसा करना याद नहीं है, और प्रासंगिक अनुभागों को स्किम करना अब मुझे वह दिखाई नहीं दे रहा है। लेकिन शायद मुझे कुछ याद आया?

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

यदि क्रॉस-मॉड्यूल कॉल के नीचे await s को ट्रैप में परिभाषित किया गया है, तो इसके लिए कॉल स्टैक को ट्रैवर्सल निर्दिष्ट करने की आवश्यकता होगी ताकि यह निरीक्षण किया जा सके कि होस्ट से आमंत्रण द्वारा बनाए गए अंतिम डमी फ्रेम से पहले क्रॉस-मॉड्यूल कॉल मौजूद है या नहीं। (§ 4.5.5)। यह कल्पना में एक दुर्भाग्यपूर्ण जटिलता होगी। लेकिन मैं रॉस से सहमत हूं कि क्रॉस-मॉड्यूल कॉल ट्रैप होना संरचना का उल्लंघन होगा, इसलिए मैं उन शब्दों को पसंद करूंगा जहां पूरे स्टैक को मेजबान से अंतिम आमंत्रण पर वापस जमा दिया जाता है। कल्पना करने का सबसे आसान तरीका यह होगा कि await को होस्ट फंक्शन इनवोकेशन (§ 4.4.7.3) के समान बनाया जाए, जैसा कि आप कहते हैं, @kripken। लेकिन होस्ट फ़ंक्शन इनवोकेशन पूरी तरह से गैर-निर्धारिती हैं, इसलिए कोर स्पेक बिंदु से निर्देश के लिए एक बेहतर नाम undefined हो सकता है। और इस बिंदु पर मैं वास्तव में एक आंतरिक आयात को प्राथमिकता देना शुरू करता हूं जो हमेशा वेब प्लेटफॉर्म (और पोर्टेबिलिटी के लिए WASI) द्वारा प्रदान किया जाएगा क्योंकि कोर स्पेक, अपने आप में, undefined निर्देश IMO होने से लाभ नहीं उठाता है।

tlively 20 मई 2020

अर्थात्, मेजबान वातावरण के लिए एक कॉल जो waitref प्लस एक await लौटाता है, वह केवल एक अवरुद्ध कॉल है, है ना?

यह गैर-वेब एम्बेडिंग को क्या मूल्य प्रदान करता है जिसमें ब्राउज़र जैसा एसिंक्रोनस वातावरण नहीं होता है और मूल रूप से अवरुद्ध कॉल का समर्थन कर सकता है?

lachlansneff 20 मई 2020

@RReverser , मैं उस बिंदु को देखता हूं जो आप इंट्रिनिक्स के बारे में बना रहे हैं। निर्णय लेने में एक निर्णय कॉल शामिल होता है जब एक ऑपरेशन को बिना व्याख्या किए गए कार्यों बनाम निर्देशों के माध्यम से परिभाषित किया जाना चाहिए। मुझे लगता है कि इस फैसले में एक कारक यह विचार करना है कि यह अन्य निर्देशों के साथ कैसे इंटरैक्ट करता है। memory.grow अन्य स्मृति निर्देशों के व्यवहार को प्रभावित करता है। मुझे थ्रेड प्रस्ताव को पढ़ने का मौका नहीं मिला है, लेकिन मुझे लगता है कि atomic.wait अन्य सिंक्रनाइज़ेशन निर्देशों के व्यवहार से प्रभावित या प्रभावित होता है। इन इंटरैक्शन को औपचारिक रूप देने के लिए कल्पना को अद्यतन किया जाना है।

लेकिन await सभी के साथ, अन्य निर्देशों के साथ कोई इंटरैक्शन नहीं है। केवल मेजबान के साथ बातचीत होती है, इसलिए मेरा अंतर्ज्ञान यह होगा कि यह प्रस्ताव आयातित मेजबान कार्यों के माध्यम से किया जाना चाहिए।

RossTate 20 मई 2020

मुझे लगता है कि atomic.wait और इस प्रस्तावित await के बीच एक बड़ा अंतर यह है कि मॉड्यूल को atomic.wait के साथ फिर से दर्ज नहीं किया जा सकता है। एजेंट को पूरी तरह से सस्पेंड कर दिया गया है।

taralx 20 मई 2020

@क्रिपकेन :

@rossberg की आखिरी प्रस्तुति से मेरी समझ यह है कि वह शुरू में उस मार्ग से नीचे जाना चाहता था, लेकिन फिर कोरआउट दृष्टिकोण करने के लिए दिशा बदल दी। "समस्याएं" शीर्षक वाली स्लाइड देखें। उस स्लाइड के बाद, coroutines का वर्णन किया गया है, जो इस स्थान में एक और विकल्प हैं। तो हो सकता है कि आपका प्रश्न @rossberg के लिए अधिक हो जो शायद स्पष्ट कर सके?

हां, इसलिए coroutine-ish गुणनखंड को पिछले पुन: प्रयोज्य-अपवाद डिजाइन के सामान्यीकरण के रूप में माना जा सकता है। यह अभी भी फिर से शुरू करने योग्य घटनाओं/अपवादों की एक ही धारणा है, लेकिन try निर्देश छोटे आदिम में विघटित हो गया है - जो अर्थशास्त्र को सरल और लागत मॉडल को अधिक स्पष्ट बनाता है। यह कुछ अधिक अभिव्यंजक भी है।

आशय अभी भी यह है कि यह सभी प्रासंगिक नियंत्रण सार को व्यक्त कर सकता है, और async प्रेरक उपयोग के मामलों में से एक है। JS async के साथ इंटरऑप करने के लिए, JS API संभवतः एक पूर्वनिर्धारित await ईवेंट प्रदान कर सकता है (JS वादे को एक एक्सटर्नरेफ़ के रूप में लेकर) कि एक Wasm मॉड्यूल आयात कर सकता है और निलंबित करने के लिए throw । बेशक, बहुत सारे विवरण हैं जिन्हें बाहर निकालना होगा, लेकिन सिद्धांत रूप में यह संभव होना चाहिए।

वर्तमान प्रस्ताव के लिए, मैं अभी भी इसके चारों ओर अपना सिर लपेटने की कोशिश कर रहा हूं। :)

विशेष रूप से, ऐसा लगता है कि किसी भी पुराने Wasm फ़ंक्शन में await की अनुमति है, क्या मैं इसे सही ढंग से पढ़ रहा हूं? यदि ऐसा है, तो यह JS से बहुत अलग है, जो केवल async फ़ंक्शन में await की अनुमति देता है। और यह एक बहुत ही केंद्रीय बाधा है, क्योंकि यह इंजनों को एकल (async) फ़ंक्शन के _local_ रूपांतरण द्वारा await को संकलित करने में सक्षम बनाता है!

उस बाधा के बिना, इंजनों को या तो एक _global_ प्रोग्राम परिवर्तन (जैसे माना जाता है कि Asyncify करता है) करने की आवश्यकता होगी, जहां हर कॉल संभावित रूप से बहुत अधिक महंगी हो जाएगी (आप आमतौर पर यह नहीं जान सकते हैं कि कुछ कॉल प्रतीक्षा तक पहुंच सकती हैं)। या, समान रूप से, इंजनों को कई स्टैक बनाने और उनके बीच स्विच करने में सक्षम होने की आवश्यकता होगी!

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

rossberg 20 मई 2020

@ रोसबर्ग

विशेष रूप से, ऐसा लगता है कि किसी पुराने वासम फ़ंक्शन में प्रतीक्षा की अनुमति है, क्या मैं इसे सही ढंग से पढ़ रहा हूं? यदि ऐसा है, तो यह JS से बहुत अलग है, जो केवल async फ़ंक्शन में प्रतीक्षा की अनुमति देता है।

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

और यह एक बहुत ही केंद्रीय बाधा है, क्योंकि यह इंजन को एकल (async) फ़ंक्शन के स्थानीय परिवर्तन द्वारा प्रतीक्षा को संकलित करने में सक्षम बनाता है! उस बाधा के बिना, इंजनों को या तो एक वैश्विक कार्यक्रम परिवर्तन (जैसे माना जाता है कि Asyncify करता है) करने की आवश्यकता होगी, जहां प्रत्येक कॉल संभावित रूप से अधिक महंगी हो जाएगी (आप आमतौर पर यह नहीं जान सकते कि कुछ कॉल प्रतीक्षा तक पहुंच सकती है)। या, समान रूप से, इंजनों को कई स्टैक बनाने और उनके बीच स्विच करने में सक्षम होने की आवश्यकता होगी!

निश्चित रूप से एक वैश्विक कार्यक्रम परिवर्तन का इरादा यहाँ नहीं है! क्षमा करें यदि यह स्पष्ट नहीं था।

जैसा कि प्रस्ताव में उल्लेख किया गया है, स्टैक के बीच स्विच करना एक संभावित कार्यान्वयन विकल्प है, लेकिन ध्यान दें कि यह कोरआउट स्टाइल स्टैक स्विचिंग के समान नहीं है:

केवल संपूर्ण wasm उदाहरण रुक सकता है। यह मॉड्यूल के अंदर स्टैक स्विचिंग के लिए नहीं है। (विशेष रूप से, यही कारण है कि इस प्रस्ताव में कोर वासम स्पेक में कोई जोड़ नहीं हो सकता है और पूरी तरह से जेएस पक्ष पर हो सकता है; अब तक कुछ लोग इसे पसंद करते हैं, और मुझे लगता है कि कोई भी तरीका काम कर सकता है।)
Coroutines स्पष्ट रूप से स्टैक घोषित करता है, प्रतीक्षा नहीं करता है।
प्रतीक्षा स्टैक को केवल एक बार फिर से शुरू किया जा सकता है, कोई फोर्किंग / एक से अधिक बार लौटना नहीं है (सुनिश्चित नहीं है कि आपके प्रस्ताव में यह होगा या नहीं?)
यहां प्रदर्शन मॉडल बहुत अलग है। प्रतीक्षा जेएस में एक वादे पर प्रतीक्षा करने जा रही है, जिसमें पहले से ही न्यूनतम ओवरहेड और विलंबता है। तो यह ठीक है अगर कार्यान्वयन में कुछ ओवरहेड होता है जब हम वास्तव में रुकते हैं, और हम शायद coroutines से कम परवाह करते हैं।

उन कारकों को देखते हुए, और इस प्रस्ताव का अवलोकन योग्य व्यवहार यह है कि एक संपूर्ण wasm उदाहरण रुक जाता है, इसे लागू करने के कई तरीके हो सकते हैं। उदाहरण के लिए, एक वीएम में वेब से बाहर एक एकल wasm उदाहरण चल रहा है, यह सचमुच अपने ईवेंट लूप को तब तक चला सकता है जब तक कि यह wasm को फिर से शुरू करने का समय न हो। वेब पर, एक कार्यान्वयन दृष्टिकोण हो सकता है: जब कोई प्रतीक्षा होती है, तो पूरे वास्म स्टैक की प्रतिलिपि बनाएँ, वर्तमान स्थिति से जहाँ हमने वासम में बुलाया था; उस तरफ बचाओ; फिर से शुरू करने के लिए, इसे वापस कॉपी करें और बस वहां से आगे बढ़ें। इन पर अन्य दृष्टिकोण या भिन्नताएं भी हो सकती हैं (कुछ शायद बिना कॉपी किए, लेकिन फिर से, कॉपी ओवरहेड से बचना वास्तव में यहां महत्वपूर्ण नहीं है!)

लंबी पोस्ट के लिए खेद है, और प्रस्ताव पाठ से ही कुछ दोहराव, लेकिन मुझे आशा है कि इससे आपके द्वारा संदर्भित कुछ बिंदुओं को स्पष्ट करने में मदद मिलेगी?

मुझे लगता है कि कार्यान्वयन के संदर्भ में यहां चर्चा करने के लिए बहुत कुछ है। ल्यूसेट के बारे में अब तक @acfoltzer की टिप्पणी उत्साहजनक है!

kripken 20 मई 2020

@kripken की सबसे हालिया टिप्पणी में कुछ वाक्यांशों को स्पष्ट करने के लिए, यह संपूर्ण wasm उदाहरण नहीं है जो रुक जाता है। यह रुके हुए स्टैक पर होस्ट फ्रेम से wasm में सबसे हालिया कॉल है, और फिर होस्ट फ्रेम को इसके बजाय एक संबंधित वादा (या होस्ट के लिए उपयुक्त एनालॉग) वापस कर दिया जाता है। प्रासंगिक पूर्व स्पष्टीकरण के लिए यहां देखें।

RossTate 20 मई 2020

👍1

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

rossberg 20 मई 2020

@ रोसबर्ग

यह कुछ VMs पर सच हो सकता है, हाँ। यदि प्रतीक्षा करें और कोरआउट को ठीक उसी वीएम कार्य की आवश्यकता है, तो कम से कम किसी अतिरिक्त कार्य की आवश्यकता नहीं है। उस स्थिति में, प्रतीक्षित प्रस्ताव का लाभ सुविधाजनक जेएस एकीकरण होगा।

kripken 20 मई 2020

मुझे लगता है कि यदि आप मॉड्यूल को फिर से दर्ज करने की अनुमति नहीं देते हैं तो आप पूरे कार्यक्रम परिवर्तन के बिना सुविधाजनक जेएस एकीकरण प्राप्त कर सकते हैं।

taralx 21 मई 2020

मुझे लगता है कि यदि आप मॉड्यूल को फिर से दर्ज करने की अनुमति नहीं देते हैं तो आप पूरे कार्यक्रम परिवर्तन के बिना सुविधाजनक जेएस एकीकरण प्राप्त कर सकते हैं।

यह इसे करने का एक आसान तरीका लगता है, लेकिन इसके लिए कॉल स्टैक (या पहले चरण के रूप में, सभी WebAssembly मॉड्यूल) में देखे गए किसी भी मॉड्यूल को अवरुद्ध करने की आवश्यकता होगी।

carlopi 21 मई 2020

यह इसे करने का एक आसान तरीका लगता है, लेकिन इसके लिए कॉल स्टैक (या पहले चरण के रूप में, सभी WebAssembly मॉड्यूल) में देखे गए किसी भी मॉड्यूल को अवरुद्ध करने की आवश्यकता होगी।

ठीक है, जैसे atomic.wait ।

taralx 21 मई 2020

@taralx

मुझे लगता है कि यदि आप मॉड्यूल को फिर से दर्ज करने की अनुमति नहीं देते हैं तो आप पूरे कार्यक्रम परिवर्तन के बिना सुविधाजनक जेएस एकीकरण प्राप्त कर सकते हैं।

एक ओर पुन: प्रवेश उपयोगी हो सकता है, उदाहरण के लिए, एक गेम इंजन एक फ़ाइल डाउनलोड कर सकता है और नहीं चाहता कि ऐसा करते समय UI को पूरी तरह से रोका जाए (Asyncify आज इसकी अनुमति देता है)। लेकिन दूसरी ओर, शायद पुन: प्रवेश की अनुमति नहीं दी जा सकती है, लेकिन एक आवेदन उसके लिए एक ही मॉड्यूल के कई उदाहरण बना सकता है (सभी एक ही स्मृति, परिवर्तनीय ग्लोबल्स इत्यादि आयात कर रहे हैं?), इसलिए एक पुन: प्रविष्टि एक कॉल होगी दूसरे उदाहरण के लिए। मुझे लगता है कि हम उस काम को टूलचेन में कर सकते हैं (एक बार में सक्रिय पुन: प्रविष्टियों की संख्या पर एक प्रभावी सीमा होगी - उदाहरणों की संख्या के बराबर - जो ठीक लगता है)।

तो यदि आपका सरलीकरण वीएम की मदद करेगा तो यह निश्चित रूप से विचार करने योग्य है!

(ध्यान दें कि जैसा कि पहले चर्चा की गई थी, मुझे नहीं लगता कि हमें यहां किसी भी विकल्प पर चर्चा के साथ एक संपूर्ण कार्यक्रम परिवर्तन की आवश्यकता है। आपको केवल इसकी आवश्यकता है कि यदि आप खराब स्थिति में हैं तो Asyncify में है, जहां यह सब आप कर सकते हैं टूलचेन स्तर। प्रतीक्षा के लिए, सबसे खराब स्थिति में, जैसा कि @rossberg के साथ चर्चा की गई है, आप वह कर सकते हैं जो कोरआउट्स प्रस्ताव आंतरिक रूप से करेगा। लेकिन आपका विचार संभावित रूप से बहुत दिलचस्प है अगर यह चीजों को उससे अधिक सरल बनाता है!)

kripken 21 मई 2020

एक ओर पुन: प्रवेश उपयोगी हो सकता है, उदाहरण के लिए, एक गेम इंजन एक फ़ाइल डाउनलोड कर सकता है और नहीं चाहता कि ऐसा करते समय UI को पूरी तरह से रोका जाए (Asyncify आज इसकी अनुमति देता है)।

मुझे यकीन नहीं है कि यह एक ध्वनि सुविधा है। मुझे ऐसा लगता है कि यह हालांकि आवेदन में _unexpected concurrency_ पेश करेगा। एक मूल एप्लिकेशन जो प्रतिपादन करते समय संपत्ति लोड करता है, आंतरिक रूप से 2 धागे का उपयोग करेगा, और प्रत्येक थ्रेड वेबवर्कर + SharedArrayBuffer पर मैप करेगा। यदि कोई एप्लिकेशन थ्रेड्स का उपयोग करता है तो वह वेबवर्कर्स से सिंक्रोनस वेब प्राइमेटिव का भी उपयोग कर सकता है (जैसा कि उन्हें अनुमति है, कम से कम कुछ मामलों में)। अन्यथा एटॉमिक्स.वेट (उदाहरण के लिए) का उपयोग करके किसी कार्यकर्ता में ब्लॉकिंग ऑपरेशंस के लिए मुख्य थ्रेड में एसिंक ऑपरेशंस को मैप करना हमेशा संभव होता है।

मुझे आश्चर्य है कि सामान्य रूप से मल्टीथ्रेडिंग द्वारा संपूर्ण उपयोग केस पहले से हल नहीं हुआ है। एक कार्यकर्ता में ब्लॉकिंग प्राइमेटिव्स का उपयोग करके पूरे स्टैक (JS/Wasm/ब्राउज़र नेटिव) को संरक्षित किया जाता है जो कि बहुत सरल और मजबूत लगता है।

alexp-sssup 21 मई 2020

एक कार्यकर्ता में ब्लॉकिंग प्राइमेटिव्स का उपयोग करके पूरे स्टैक (JS/Wasm/ब्राउज़र नेटिव) को संरक्षित किया जाता है जो कि बहुत सरल और मजबूत लगता है।

यह वास्तव में स्टैंडअलोन Asyncify JS रैपर का एक और वैकल्पिक कार्यान्वयन है जिसका मैंने प्रयोग किया है, लेकिन, जब यह कोड आकार की समस्या को हल करता है, तो प्रदर्शन ओवरहेड वर्तमान Asyncify से भी अधिक था जो Wasm परिवर्तन का उपयोग करता है।

RReverser 21 मई 2020

@alexp-sssup

ऐसा लगता है कि यह हालांकि आवेदन में अप्रत्याशित समेकन पेश करेगा।

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

@RReverser ने जो कहा, उसे जोड़ने के लिए, थ्रेड्स के साथ एक और मुद्दा यह है कि उनके लिए समर्थन सार्वभौमिक नहीं है और न ही होगा । लेकिन प्रतीक्षा हर जगह हो सकती है।

kripken 21 मई 2020

👍1

अन्य भाषाओं में जहां async/प्रतीक्षा की शुरुआत की गई है, पुन: प्रवेश बिल्कुल महत्वपूर्ण है। इस तरह की पूरी बात यह है कि अन्य घटनाएं तब हो सकती हैं जब कोई (ए) प्रतीक्षा कर रहा हो। मुझे ऐसा लगता है कि पुन: प्रवेश बहुत महत्वपूर्ण है।

इसके अलावा, क्या यह सच नहीं है कि जब भी कोई मॉड्यूल किसी बाहरी फ़ंक्शन के लिए कोई कॉल करता है तो उसे यह मान लेना पड़ता है कि इसे अपने किसी भी निर्यात के माध्यम से फिर से दर्ज किया जा सकता है (उपरोक्त उदाहरण में, बिना किसी प्रतीक्षा के, किसी भी कॉल और बाहरी मॉलोक को कॉल करने के लिए फ़ंक्शन मुफ़्त है (कोई इरादा नहीं है)।

sbc100 21 मई 2020

👍2

एक एप्लिकेशन उसके लिए एक ही मॉड्यूल के कई उदाहरण बना सकता है (सभी एक ही मेमोरी, म्यूटेबल ग्लोबल्स इत्यादि आयात कर रहे हैं?), इसलिए एक पुन: प्रविष्टि किसी अन्य उदाहरण के लिए कॉल होगी

केवल मॉड्यूल की साझा यादों के लिए। अन्य यादों को फिर से चालू करना पड़ता है, जो एक ऑपरेशन स्टॉम्प पर दूसरे ऑपरेशन इन-फ्लाइट परिवर्तनों से बचने के लिए महत्वपूर्ण है।

taralx 22 मई 2020

👍1

मैं ध्यान देता हूं कि इसका गैर-रीएंट्रेंट संस्करण थ्रेड समर्थन के साथ किसी भी एम्बेडिंग पर पॉलीफ़िल करने योग्य है, अगर कोई इसके साथ खेलना चाहता है और देखें कि यह कितना उपयोगी है।

taralx 22 मई 2020

मैं ध्यान देता हूं कि इसका गैर-रीएंट्रेंट संस्करण थ्रेड समर्थन के साथ किसी भी एम्बेडिंग पर पॉलीफ़िल करने योग्य है, अगर कोई इसके साथ खेलना चाहता है और देखें कि यह कितना उपयोगी है।

जैसा कि ऊपर उल्लेख किया गया है, यह कुछ ऐसा है जिसके साथ हम पहले ही खेल चुके हैं, लेकिन इसे छोड़ दिया गया क्योंकि यह वर्तमान समाधान की तुलना में और भी खराब प्रदर्शन लाता है, सार्वभौमिक रूप से समर्थित नहीं है, और इसके अतिरिक्त WebAssembly.Global या WebAssembly.Table साझा करना बहुत कठिन हो जाता है अतिरिक्त हैक्स के बिना मुख्य धागे के साथ, यह पारदर्शी पॉलीफिल के लिए एक खराब विकल्प बनाता है।

वर्तमान समाधान जो वासम मॉड्यूल को फिर से लिखता है, इन मुद्दों से ग्रस्त नहीं है, बल्कि इसके बजाय महत्वपूर्ण फ़ाइल आकार की लागत है।

जैसे, इनमें से कोई भी बड़ी वास्तविक दुनिया के ऐप्स के लिए अच्छा नहीं है, जो हमें यहां वर्णित एसिंक्रोनस एकीकरण के लिए मूल समर्थन देखने के लिए प्रेरित करता है।

RReverser 22 मई 2020

खराब प्रदर्शन

क्या आपके पास किसी प्रकार का बेंचमार्क है?

taralx 23 मई 2020

हाँ, मैं इसे तब साझा कर सकता हूँ जब मैं मंगलवार (या, अधिक संभावना, बुधवार) को काम पर वापस आ जाता हूँ, या एक को व्हिप करना काफी आसान है जो केवल en खाली async JS फ़ंक्शन को स्वयं कॉल करता है।

RReverser 23 मई 2020

धन्यवाद। मैं एक माइक्रोबेंचमार्क बना सकता था, लेकिन यह बहुत शिक्षाप्रद नहीं होगा।

taralx 24 मई 2020

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

RReverser 24 मई 2020

माइक्रोबेंचमार्क के साथ समस्या यह है कि हम नहीं जानते कि वास्तविक एप्लिकेशन के लिए कितनी विलंबता स्वीकार्य है। यदि यह अतिरिक्त 1ms लेता है, तो क्या यह वास्तव में एक समस्या है यदि एप्लिकेशन केवल 1/s दर पर प्रतीक्षा संचालन करता है, उदाहरण के लिए?

taralx 24 मई 2020

मुझे लगता है कि परमाणु-आधारित दृष्टिकोण की गति पर ध्यान एक विकर्षण हो सकता है। जैसा कि पहले उल्लेख किया गया है कि परमाणु हर जगह काम नहीं करते हैं (सीओओपी/सीओईपी के कारण) और केवल एक कार्यकर्ता परमाणु दृष्टिकोण का उपयोग कर सकता है क्योंकि मुख्य धागा अवरुद्ध नहीं हो सकता है। यह एक साफ-सुथरा विचार है, लेकिन एक सार्वभौमिक समाधान के लिए हमें प्रतीक्षा की तरह कुछ चाहिए।

kripken 24 मई 2020

मैं इसे दीर्घकालिक समाधान के रूप में नहीं सुझा रहा हूं। मैं एक पॉलीफिल का सुझाव दे रहा हूं जो इसका उपयोग करता है यह देखने के लिए इस्तेमाल किया जा सकता है कि क्या एक गैर-पुनर्प्रवेश समाधान लोगों के लिए काम करेगा।

taralx 25 मई 2020

@taralx ओह, ठीक है, अब मैं देखता हूं, धन्यवाद।

kripken 25 मई 2020

@taralx :

मुझे लगता है कि यदि आप मॉड्यूल को फिर से दर्ज करने की अनुमति नहीं देते हैं तो आप पूरे कार्यक्रम परिवर्तन के बिना सुविधाजनक जेएस एकीकरण प्राप्त कर सकते हैं।

यह बुरा होगा। इसका मतलब है कि कई मॉड्यूल को मर्ज करने से उनका व्यवहार टूट सकता है। यह प्रतिरूपकता का विरोधी होगा।

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

rossberg 25 मई 2020

👍2

@rossberg : जैसा कि पहले प्रस्तावित किया गया था, यह किसी भी Wasm मॉड्यूल तक पहुंच को अवरुद्ध करने के रूप में सामान्यीकृत है। लेकिन तब यह शायद बहुत सीमित है।

carlopi 25 मई 2020

यह बुरा होगा। इसका मतलब है कि कई मॉड्यूल को मर्ज करने से उनका व्यवहार टूट सकता है। यह प्रतिरूपकता का विरोधी होगा।

पॉलीफिलिंग तर्क के साथ यह मेरी बात थी - atomic.wait प्रतिरूपकता को नहीं तोड़ता है, इसलिए यह भी नहीं होना चाहिए।

taralx 25 मई 2020

@taralx , atomic.wait एक विशिष्ट मेमोरी में एक विशिष्ट स्थान का संदर्भ देता है। कौन सी मेमोरी और स्थान await ब्लॉकिंग का उपयोग करेगा, और कोई कैसे नियंत्रित करेगा कि कौन से मॉड्यूल उस मेमोरी को साझा करते हैं?

rossberg 25 मई 2020

@rossberg क्या आप उस परिदृश्य के बारे में विस्तार से बता सकते हैं जो आपको लगता है कि यह टूट जाता है? मुझे संदेह है कि हमारे पास अलग-अलग विचार हैं कि गैर-पुनर्वित्तक संस्करण कैसे काम करेगा।

taralx 25 मई 2020

@taralx , दो मॉड्यूल ए और बी लोड करने पर विचार करें, प्रत्येक कुछ निर्यात फ़ंक्शन प्रदान करता है, A.f और B.g कहें। कॉल किए जाने पर दोनों await प्रदर्शन कर सकते हैं। क्लाइंट कोड के दो टुकड़े क्रमशः इन कार्यों में से प्रत्येक को पारित कर देते हैं, और वे उन्हें स्वतंत्र रूप से कहते हैं। वे एक दूसरे को बाधित या अवरुद्ध नहीं करते हैं। फिर कोई कोड के बारे में कुछ भी बदले बिना ए और बी को सी में विलय या रिफैक्टर करता है। अचानक क्लाइंट कोड के दोनों टुकड़े एक दूसरे को अप्रत्याशित रूप से अवरुद्ध करना शुरू कर सकते हैं। छिपे हुए साझा राज्य के माध्यम से दूरी पर डरावना कार्रवाई।

rossberg 25 मई 2020

👍1

यह समझ आता है। लेकिन मॉड्यूल में पुन: प्रवेश जोखिम संगामिति की अनुमति देता है जो इसकी अपेक्षा नहीं करता है, इसलिए यह किसी भी तरह से दूरी पर डरावना कार्रवाई है।

taralx 25 मई 2020

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

sbc100 25 मई 2020

👍2

(संपादित)

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

taralx 25 मई 2020

जब कोड चल रहा होता है, और यह एक फ़ंक्शन को कॉल करता है, तो दो संभावनाएं होती हैं: यह जानता है कि फ़ंक्शन यादृच्छिक चीज़ों को कॉल नहीं करेगा, या फ़ंक्शन यादृच्छिक चीज़ों को कॉल कर सकता है। बाद के मामले में, पुन: प्रवेश हमेशा संभव है। वही नियम await पर लागू होते हैं।

devsnek 25 मई 2020

(ऊपर मेरी टिप्पणी संपादित)

taralx 25 मई 2020

अब तक की चर्चा के लिए सभी को धन्यवाद!

संक्षेप में, ऐसा लगता है कि यहां सामान्य रुचि है, लेकिन बड़े खुले प्रश्न हैं जैसे कि यह जेएस पक्ष पर 100% होना चाहिए या सिर्फ 99% - ऐसा लगता है जैसे पूर्व कुछ लोगों की प्रमुख चिंताओं को दूर कर देगा, और वह होगा वेब केस के लिए ठीक रहें, तो शायद यह ठीक है। एक और बड़ा खुला सवाल यह है कि वीएम में ऐसा करना कितना संभव होगा जिसके बारे में हमें और जानकारी चाहिए।

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

kripken 29 मई 2020

सिर्फ FYI करें के लिए
हम एक समान में एक पूर्ण स्टैक स्विचिंग प्रस्ताव एक साथ रखेंगे
समय सीमा। मुझे लगता है कि इससे आपका विशेष मामला भिन्न हो सकता है -
क्या सोचते हो?
फ्रांसिस

गुरु, 28 मई, 2020 को अपराह्न 3:51 बजे एलोन ज़काई नोटिफिकेशन @github.com ने लिखा:

अब तक की चर्चा के लिए सभी को धन्यवाद!
संक्षेप में, ऐसा लगता है कि यहाँ सामान्य रुचि है, लेकिन वहाँ हैं
बड़े खुले प्रश्न जैसे कि यह JS की ओर से 100% होना चाहिए या उचित
99% - ऐसा लगता है कि पूर्व कुछ लोगों की प्रमुख चिंताओं को दूर कर देगा
है, और यह वेब केस के लिए ठीक होगा, इसलिए शायद यह ठीक है।
एक और बड़ा खुला प्रश्न यह है कि VMs में ऐसा करना कितना संभव होगा?
के बारे में हमें और जानकारी चाहिए।
मैं चर्चा के लिए 2 सप्ताह में अगली सीजी बैठक के लिए एक एजेंडा आइटम का सुझाव दूंगा
इस प्रस्ताव पर विचार करें और इसे चरण 1 के लिए विचार करें, जिसका अर्थ होगा एक रेपो खोलना
और खुले प्रश्नों पर अलग-अलग मुद्दों पर और अधिक विस्तार से चर्चा करना।
(मेरा मानना है कि यह सही प्रक्रिया है, लेकिन अगर मैं गलत हूं तो कृपया मुझे सुधारें।)
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/WebAssembly/design/issues/1345#issuecomment-635649331 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAQAXUCLZ4CJVQYEUBK23BLRT3TFLANCNFSM4NEJW2PQ
.
>

फ्रांसिस मैककेबे
दुर्भाग्य

fgmccabe 29 मई 2020

@fgmccabe

हमें उस पर निश्चित रूप से चर्चा करनी चाहिए।

आम तौर पर, जब तक आपका प्रस्ताव जेएस पक्ष पर केंद्रित नहीं होता है, मुझे लगता है कि यह इसे एक महत्वपूर्ण नहीं बना देगा (जो जेएस पक्ष पर 99% -100% है)।

kripken 29 मई 2020

अब जब कार्यान्वयन विवरण पर चर्चा समाप्त हो गई है, तो मैं एक उच्च-स्तरीय चिंता को फिर से व्यक्त करना चाहूंगा जिसे मैंने पहले व्यक्त किया था लेकिन एक समय में एक चर्चा करने के लिए छोड़ दिया।

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

वेब प्रोग्राम के मामले में, अब WebAssembly के साथ इन विभिन्न घटकों को अलग-अलग भाषाओं में भी लिखा जा सकता है: JS या wasm। वास्तव में, कई घटकों को किसी भी भाषा में ठीक वैसे ही लिखा जा सकता है; मैं इन्हें "द्विपक्षीय" घटकों के रूप में संदर्भित करूंगा। अभी, अधिकांश उभयलिंगी घटक जेएस में लिखे गए हैं, लेकिन मुझे लगता है कि हम सभी उम्मीद कर रहे हैं कि उनमें से अधिक से अधिक वासम में फिर से लिखे जाएंगे। इस "कोड माइग्रेशन" को सुविधाजनक बनाने के लिए, हमें यह सुनिश्चित करने का प्रयास करना चाहिए कि इस तरह से एक घटक को फिर से लिखने से यह नहीं बदलता है कि यह पर्यावरण के साथ कैसे इंटरैक्ट करता है। एक खिलौने के उदाहरण के रूप में, चाहे कोई विशेष "लागू करें" प्रोग्राम घटक (f, x) => f(x) JS में लिखा गया हो या wasm में समग्र कार्यक्रम के व्यवहार को प्रभावित नहीं करना चाहिए। यह एक कोड-माइग्रेशन सिद्धांत है।

दुर्भाग्य से, इस प्रस्ताव के सभी प्रकार या तो मॉड्यूल-रचना कार्यक्रम या कोड-माइग्रेशन सिद्धांत का उल्लंघन करते हैं। पूर्व का उल्लंघन तब किया जाता है जब await उस स्टैक को कैप्चर करता है जहां वर्तमान wasm मॉड्यूल सबसे हाल ही में दर्ज किया गया था, क्योंकि यह सीमा बदल जाती है क्योंकि मॉड्यूल अलग हो जाते हैं या एक साथ जुड़ जाते हैं। उत्तरार्द्ध का उल्लंघन तब किया जाता है जब await उस स्टैक को पकड़ लेता है जहां तक wasm सबसे हाल ही में दर्ज किया गया था, क्योंकि यह सीमा बदल जाती है क्योंकि कोड JS से wasm में माइग्रेट हो जाता है (ताकि (f, x) => f(x) से कुछ सरल माइग्रेट हो जाए JS to wasm समग्र कार्यक्रम के व्यवहार को महत्वपूर्ण रूप से बदल सकता है)।

मुझे नहीं लगता कि ये उल्लंघन इस प्रस्ताव के खराब डिजाइन विकल्पों के कारण हैं। बल्कि, समस्या यह प्रतीत होती है कि यह प्रस्ताव अप्रत्यक्ष रूप से जेएस को और अधिक शक्तिशाली बनाने से बचने की कोशिश कर रहा है, और वह लक्ष्य इन सिद्धांतों का उल्लंघन करने वाली कृत्रिम सीमाओं को लागू करने के लिए मजबूर कर रहा है। मैं उस लक्ष्य को पूरी तरह से समझता हूं, लेकिन मुझे संदेह है कि यह समस्या अधिक से अधिक सामने आएगी: WebAssembly में कार्यक्षमता को इस तरह से जोड़ना जो इन सिद्धांतों का सम्मान करता है, अक्सर जेएस को एम्बेडिंग भाषा होने के कारण परोक्ष रूप से जेएस में कार्यक्षमता जोड़ने की आवश्यकता होगी। मेरी प्राथमिकता उस मुद्दे से निपटने के लिए होगी (जो मुझे वास्तव में नहीं पता कि कैसे हल किया जाए)। यदि ऐसा नहीं है, तो मेरी माध्यमिक प्राथमिकता केवल JS API में यह परिवर्तन करना होगा, क्योंकि यह JS है जो यहाँ सीमित कारक है, बजाय WebAssembly को निर्देश जोड़ने के लिए कि wasm की कोई व्याख्या नहीं है।

RossTate 1 जून 2020

👍2

मुझे नहीं लगता कि ये उल्लंघन इस प्रस्ताव के खराब डिजाइन विकल्पों के कारण हैं। बल्कि, समस्या यह प्रतीत होती है कि यह प्रस्ताव परोक्ष रूप से जेएस को और अधिक शक्तिशाली बनाने से बचने की कोशिश कर रहा है

यह महत्वपूर्ण है, लेकिन यह यहां डिजाइन का मुख्य कारण नहीं है।

इस डिजाइन का मुख्य कारण यह है कि जबकि मैं पूरी तरह से सहमत हूं कि संरचना का सिद्धांत wasm के लिए समझ में आता है, हमारे पास वेब पर मूलभूत समस्या यह है कि वास्तव में JS और wasm व्यवहार में समान नहीं हैं। हमारे पास हस्तलिखित JS है जो async है और पोर्टेड wasm जो सिंक है। दूसरे शब्दों में, उनके बीच की सीमा वास्तव में ठीक वही समस्या है जिसका हम समाधान करने का प्रयास कर रहे हैं। कुल मिलाकर मुझे यकीन नहीं है कि मैं सहमत हूं कि संरचना के सिद्धांत को wasm और JS पर लागू किया जाना चाहिए (लेकिन शायद यह एक दिलचस्प बहस हो सकती है)।

kripken 1 जून 2020

👍1

kripken 3 जून 2020

👍7 ❤4

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Design: प्रस्ताव: प्रतीक्षित

संक्षेप में विचार

विवरण

कोर वासम स्पेक

वासम जेएस स्पेक

टूलचेन / लाइब्रेरी सपोर्ट

कार्यान्वयन और प्रदर्शन

स्पष्टीकरण

अन्य प्रस्तावों से जुड़ाव

अपवाद

कोरटाइन्स

WASI#276

कोने का मामला: wasm उदाहरण => wasm उदाहरण => प्रतीक्षा

वैकल्पिक तरीकों पर विचार किया गया

पिछली संबंधित चर्चा

सबसे उपयोगी टिप्पणी

सभी 96 टिप्पणियाँ

>

संबंधित मुद्दों