Design: Apa itu utas Majelis Web?

Sepertinya ada versi emscripten-fastcomp yang menggunakan WebWorkers untuk mengimplementasikan utas:
https://github.com/juj/emscripten-fastcomp/tree/pthreads

Karena utas saat ini terdaftar sebagai fitur pasca-v1 , apakah kita perlu menyelesaikannya sebelum pengumuman publik?

Setuju, pindah ke tidak ada tonggak.

Terkait dengan masalah ini, di #103 saya menyarankan agar kita melihat jaminan kemajuan ke depan sebagaimana didefinisikan dalam komite standar C++.

Ini adalah pertanyaan penting. Secara umum, saya telah mengambil sikap bahwa kita harus bekerja keras untuk menghindari duplikasi bagian lain dari platform Web dengan akhirnya mengizinkan akses API Web langsung dari WebAssembly . Yang sedang berkata, utas adalah bagian inti dari semantik eksekusi, membuatnya lebih seperti SIMD (builtin yang jelas) daripada WebGL (API eksternal yang jelas).

Selama diskusi awal dengan @ncbray tentang pekerja vs. versi utas WebAssembly murni, saya melihat situasinya sebagai salah satu atau dan berpihak pada pekerja. Baru-baru ini, saya menyadari bahwa keduanya bisa sangat saling melengkapi. Pertama izinkan saya menjelaskan keduanya secara independen sebelum menjelaskan bagaimana mereka menulis:

Dengan _utas berbasis pekerja_, untuk membuat utas, aplikasi wasm akan membuat pekerja (di v.1, dengan memanggil JS; setelah integrasi WebIDL, dengan mengimpor API Pekerja dan membuat pekerja secara langsung). Untuk berbagi wasm heap/global-state antar pekerja, objek modul wasm itu sendiri akan postMessage() ed langsung ke pekerja tujuan, simetris dengan bagaimana seseorang berbagi SharedArrayBuffer ( impor modul WebAssembly akan diimpor kembali di tempat tujuan).

Kelebihan:

• simetris dengan pemetaan pthreads-to-asm.js+SAB yang jelas bahwa Jukka telah bekerja dan lulus rangkaian uji pthread.
• sejumlah modul wasm dapat dibagikan di antara sejumlah pekerja yang memungkinkan konfigurasi yang sangat ekspresif dalam kasus penggunaan wasm yang tidak mencakup seluruh aplikasi.
• Tidak ada perubahan nyata untuk platform web atau API Web dibandingkan dengan JS+SAB.

Kontra:

• Pekerja saat ini agak gemuk memori (karena masing-masing menyertakan konteks eksekusi JS independen ( JSRuntime / Isolate , dll)).
• Meskipun pasti _mungkin_ bagi pekerja untuk menghindari pembuatan konteks JS jika tidak ada JS yang diimpor dalam pekerja (setelah kami memiliki integrasi wasm+WebIDL), ini tidak akan menjadi tugas impl sederhana (karena ketergantungan yang tidak disengaja dan lintas sektoral sifat pekerja). Juga, ada kasus impor dinamis JS (pada pekerja yang sebelumnya bebas JS) dan overhead non-JS yang mungkin lebih sulit untuk diberantas. Pasti tertarik untuk mendengar apa yang dikatakan browser lain tentang ini. Tapi saya khawatir utas tidak akan dapat diandalkan di semua browser selama bertahun-tahun.

Jadi, alternatifnya adalah utas yang ditentukan oleh WebAssembly murni. Pada dasarnya, spesifikasi akan menentukan cara Anda membuat, menghancurkan, menggabungkan, dll. Utas akan secara logis "di dalam" modul dan semua utas akan memiliki akses ke global yang sama, impor, dll. Apa yang terjadi ketika utas non-utama memanggil impor yang (di browser) adalah JS? (Seluruh ide dari @ncbray) Utas panggilan akan diblokir dan panggilan akan dieksekusi pada utas utama modul (utas tempat modul dimuat, yang memiliki Realm dll yang terdefinisi dengan baik) , seolah-olah oleh setTimeout(importedFun.bind(args to import call)) .

Kelebihan:

• Secara konstruksi, setiap utas yang dibuat WebAssembly tidak lain adalah utas OS. Tidak ada pekerjaan khusus yang diperlukan untuk melangsingkan yang berarti utas biaya OS dari hari pertama di semua browser yang menerapkan fitur tersebut.
• Kami mungkin akhirnya menginginkan beberapa operasi pada utas yang tidak diinginkan pada pekerja (katakanlah, pthread_kill ...).

Kontra:

• Peningkatan latensi dibandingkan dengan panggilan sinkron dan hambatan serialisasi pada utas utama. Solusi di sini adalah, ketika kita mendapatkan binding WebIDL, kita dapat menentukan mekanisme keikutsertaan (misalnya, atribut metode WebIDL baru) yang dinyatakan oleh API bahwa mereka dapat dipanggil secara sinkron dari utas wasm.

Tidak melihat ini sebagai hal yang saling eksklusif menunjukkan hibrida yang menarik:

• Sebuah modul dapat dibagi dengan banyak pekerja (seperti yang dijelaskan di atas) dan, di dalam setiap pekerja, dapat melakukan fork sejumlah benang murni yang dikandung oleh pekerja+modul tersebut.
  
  
  
  • Pekerja yang mengandung akan menjadi "utas utama" untuk tujuan panggilan impor pada benang wasm murni.
  
  
• Ini memungkinkan aplikasi wasm untuk secara tepat mengontrol berapa banyak loop peristiwa dan konteks JS yang dibuatnya.
  
  
  
  • Misalnya, saya berharap game memiliki satu pekerja OffscreenCanvas (tidak ada utas wasm murni, hanya merender pada utas pekerja tanpa gangguan), satu pekerja IDB (mungkin beberapa utas wasm murni), dan satu "semua utas latar belakang lainnya" pekerja (dengan semua utas lainnya sebagai utas murni).
  
  
  • Dalam batasnya, setelah semua API Web penting telah ditandai dapat dipanggil langsung dari thread pure-wasm, aplikasi yang ideal akan secara eksklusif membuat thread pure-wasm.
  
  

Dari POV platform Web, saya pikir tidak satu pun dari ini yang secara mendasar mengubah model selama kita dengan hati-hati mendefinisikan hal-hal seperti status tumpukan objek pengaturan skrip (sekali lagi, analog dengan setTimeout ). Selain itu, utas wasm murni dapat dideskripsikan dan dapat diisi ganda dalam istilah asm.js+SAB: utas non-utama yang memanggil menggunakan memori bersama untuk mengantrekan pekerjaan untuk utas utama dan kemudian futexWait() s untuk tanggapan.

Dari POV lingkungan non-Web: hanya utas wasm murni yang akan ada sesuai dengan spesifikasi (meskipun spesifikasi akan menentukan apa yang terjadi ketika beberapa utas "lain" (baca: pekerja) memanggil fungsi secara tiba-tiba). Situasi ini akan simetris dengan impor modul di mana spesifikasi hanya berbicara tentang semantik modul tunggal, meninggalkan apa yang dapat diimpor ke lingkungan host. Secara khusus, ini berarti bahwa, dengan utas wasm murni, Anda akan dapat dengan mudah menulis modul berulir tanpa dependensi Host apa pun.

Yang paling saya sukai adalah model hybrid menghindari persyaratan semua browser untuk mengurangi pekerja mereka (yang mungkin memakan waktu bertahun-tahun dan memerlukan kolaborasi lintas organisasi). Saya, bagaimanapun, cukup tertarik untuk mendengar jika vendor browser lain berpikir bahwa ini bukan masalah besar.

Kami juga dapat mengembangkan platform web dengan dua cara:

• Izinkan beberapa API web seperti GL untuk digunakan di luar utas utama, tetapi masih hanya dari satu utas.
• Pendekatan ini tidak bekerja untuk banyak kasus penggunaan sistem file: aplikasi berharap dapat read / write dari banyak utas tanpa melakukan lompatan implisit, dan sebenarnya tidak ada alasan yang bagus untuk melarang ini. Kami dapat menentukan beberapa API untuk bekerja dari beberapa utas wasm (dengan beberapa batasan).

Kami juga ingin mengizinkan beberapa bentuk threading mode pengguna yang ringan. Bahasa lain, seperti Go, akan bekerja lebih baik dengan ini, dan C++ sendiri akan mendapatkan fitur seperti itu di C++17 atau segera setelahnya. Mari kita pastikan pendekatan kita memungkinkan hal ini.

Sejak kami berbicara, saya telah mencoba untuk mengungkap masalah interaksi yang tidak jelas dan berbulu dan titik awal yang tidak diartikulasikan (re: permukaan api + ffi + utas) dan membaginya menjadi potongan-potongan kecil yang dapat kita bicarakan. Mudah-mudahan saya akan segera mulai memposting beberapa masalah, anggap ini sebagai rintisan dukungan yang melambai tangan sampai saat itu.

Secara umum, saya pikir kita mulai melihat hal-hal dari perspektif yang sama, tetapi ada banyak masalah terkait yang perlu diselesaikan hingga detail untuk masalah ini benar.

Setelah membaca spesifikasi Web Worker, ini sangat JS-centric. Itu tidak memberi Anda banyak hal kecuali utas memiliki loop peristiwa implisit (gaya JS) dan isolat JS lokal-utas. Dalam hal ini, mungkin masuk akal untuk memperlakukannya sebagai pekerja. (Tetapi jenis utas ini mungkin tidak ada, tergantung pada pilihan desain lainnya.) Saya memiliki beberapa kekhawatiran lain tentang bagaimana masa pakai pekerja ditentukan dan fakta bahwa "asal" aplikasi dapat berbeda per utas, tetapi saya pikir masalah tersebut dapat ditangguhkan untuk saat ini.

Saya tidak percaya kami ingin pekerja menjadi "utas entah dari mana" dengan memanggil kode WASM apa pun yang mereka inginkan. ID pthreads apa yang mereka dapatkan? Bagaimana cara kerja TLS? Kecuali jika manajemen utas bersifat hermetis terhadap WASM, akan ada beberapa pertanyaan sulit untuk dijawab.

Saya suka kode WASM berinteraksi dengan pekerja yang sewenang-wenang. Sesuatu di sepanjang baris port pesan + salinan data massal, jika tidak ada yang lain? (Ya, ini sepertinya langkah mundur, saya akan mencoba membenarkannya di tempat lain.)

Mengimpor kembali modul ES6 terkait di postMessage membuat saya takut. Ini memecahkan beberapa masalah buruk tetapi juga tampak seperti palu besar yang pasti akan menghancurkan sesuatu yang lain. Aku harus memikirkan konsekuensinya.

Catatan: setidaknya di Chrome, saya tahu bahwa banyak API pekerja diimplementasikan dengan memantul melalui utas utama. Jadi secara eksplisit kemacetan melalui utas utama mungkin tidak terlalu merusak kinerja, dalam jangka pendek?

Catatan: bahkan dengan SAB, satu-satunya cara nyata untuk mengantrekan tugas pada utas dengan loop peristiwa implisit (gaya JS) adalah postMessage. Atau, kita dapat membuat semacam fungsionalitas tipe "acara pada bangun futex", tetapi itu mungkin lebih cocok untuk loop acara eksplisit (gaya asli, penyewa, dipompa oleh program).

Catatan: mutex penyimpanan implisit tampak seperti jalan buntu yang menunggu untuk terjadi, meskipun saya tidak dapat menemukan API apa pun yang benar-benar mendapatkannya di pekerja...

Pada Selasa, 9 Jun 2015 pukul 02:05, Nick Bray [email protected] menulis:

Sejak kami berbicara, saya telah mencoba untuk mengungkap bola berbulu yang tidak jelas
masalah yang berinteraksi dan titik awal yang tidak diartikulasikan (re: api surface + ffi

• utas) dan bagi menjadi potongan-potongan kecil yang bisa kita bicarakan.
  Semoga saya akan segera mulai memposting beberapa masalah, anggap ini sebagai lambaian tangan
  rintisan sakit-dukungan sampai saat itu.

Secara umum, saya pikir kita mulai melihat hal-hal dari kesamaan
perspektif, tetapi ada banyak masalah terkait yang perlu diselesaikan
melalui sampai rincian untuk masalah ini klik pada tempatnya.

Setelah membaca spesifikasi Web Worker, ini sangat JS-centric. Tidak
membelikan Anda banyak kecuali utas memiliki loop acara implisit (gaya JS)
dan isolat JS lokal-utas. Dalam hal ini, mungkin masuk akal untuk mengobatinya
sebagai pekerja. (Tapi utas semacam ini mungkin tidak ada, tergantung pada yang lain
pilihan desain.) Saya memiliki beberapa kekhawatiran lain tentang bagaimana masa hidup pekerja
ditentukan dan fakta bahwa "asal" aplikasi dapat berbeda per utas, tetapi saya
berpikir masalah tersebut dapat ditunda untuk saat ini.

Loop acara mungkin masuk akal di luar JS, juga. Misalnya ada
beberapa model yang mungkin menarik untuk dilihat, seperti janji, async IO
acara, dll. Saya tidak mengusulkan sesuatu yang konkret di sini, tapi mungkin wasm
use case akan meminta generalisasi di sini.

Saya tidak percaya kita ingin pekerja menjadi "benang entah dari mana" dengan
memanggil kode WASM apa pun yang mereka inginkan. ID pthreads apa yang mereka dapatkan?
Bagaimana cara kerja TLS? Kecuali jika manajemen utas hermetis terhadap WASM, ada
akan menjadi beberapa pertanyaan sulit untuk dijawab.

Pertanyaannya adalah bagaimana seorang pekerja masuk ke kode wasm? Mereka harus
dapatkan referensi ke modul wasm entah bagaimana, mungkin dengan memilikinya terlebih dahulu
postMessage()'d kepada mereka.

Saya suka kode WASM berinteraksi dengan pekerja yang sewenang-wenang. Sesuatu
sepanjang baris port pesan + salinan data massal, jika tidak ada yang lain? (Ya,
ini sepertinya langkah mundur, saya akan mencoba membenarkannya di tempat lain.)

Mengimpor kembali modul ES6 terkait di postMessage membuat saya takut.
Ini memecahkan beberapa masalah buruk tetapi juga tampak seperti palu besar yang akan
pasti menghancurkan sesuatu yang lain. Aku harus memikirkannya
konsekuensi.

Catatan: setidaknya di Chrome, saya tahu bahwa banyak API pekerja diimplementasikan oleh
memantul melalui utas utama. Jadi secara eksplisit menghambat melalui
utas utama mungkin tidak terlalu mengganggu kinerja, dalam jangka pendek?

Catatan: bahkan dengan SAB, satu-satunya cara nyata untuk mengantrekan tugas di utas dengan
loop peristiwa implisit (gaya JS) adalah postMessage. Atau, kita bisa
buat semacam fungsionalitas tipe "event on futex wake", tapi itu
mungkin lebih cocok untuk eksplisit (gaya asli, penyewa, dipompa oleh
program) loop acara.

Catatan: mutex penyimpanan implisit tampak seperti kebuntuan yang menunggu untuk terjadi,
meskipun saya tidak dapat menemukan API apa pun yang benar-benar mendapatkannya di pekerja ...

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/WebAssembly/spec/issues/104#issuecomment -110178097.

Setuju dengan @titzer bahwa kami mungkin ingin mendukung pemrograman gaya asinkron dengan mengizinkan wasm untuk berpartisipasi secara langsung dalam loop acara (yang bahkan bukan imajinasi). Pada tingkat tinggi, saya pikir kita akan melihat:

1. Aplikasi dengan C++ POV portabel yang tidak menginginkan asinkron apa pun, mereka menginginkan utas murni dan banyak di antaranya dan mereka dapat membatasi diri pada utas murni-wasm (menggunakan pekerja hanya untuk menghindari kemacetan hingga semua API Web penting dapat dipanggil langsung dari murni benang wasm).
2. Aplikasi dengan POV web yang terdiri dari modul JS, modul wasm, didasarkan pada kerangka kerja web populer, menggunakan banyak asinkron. Di sinilah kita pasti membutuhkan kekuatan penuh dari pekerja bersama dan integrasi yang baik dengan loop acara, janji, dll.

dan saya pikir kedua kasus penggunaan akan sangat berarti di masa mendatang.

Dari perspektif C++, kami dapat memetakan 2 POV yang diusulkan

1. Basis kode yang mengekspor _start .
2. Basis kode yang mengekspor sesuatu seperti pengendali select atau epoll .

Penerjemah (lua, python, ...) bisa muat dengan baik di 2, dan implementasi bisa mengubah pemrosesan loop acara JS dengan pemrosesan acara modul wasm, termasuk beberapa deskriptor file dan penanganan pipa yang biasanya tidak bisa dilakukan JS selain wasm modul bisa. Untuk lebih jelasnya, saya tidak mengatakan kami mengekspos epoll apa adanya, tetapi sesuatu yang dekat dengannya yang masih cocok dengan baik di platform web.

IIUC, select / epoll akan sama dengan memblokir secara serempak pada serangkaian peristiwa terbatas dari loop peristiwa. Itu telah lama diusulkan secara independen untuk pekerja di JS, dan kita mungkin harus mendorongnya ke depan (ini adalah ekstensi lintas sektoral ke platform yang kemungkinan memiliki konsekuensi semantik yang luas, bukan sesuatu yang bisa kita lakukan secara lokal di wasm), tapi saya pikir jika kita ingin berintegrasi dengan platform web _existing_, ini bukan primitif logis untuk melakukannya: kita harus mengizinkan kembali ke loop acara yang berarti meminta wasm mendaftarkan dirinya sebagai penangan onmessage pekerja (yang dapat berupa diekspresikan dengan cara wasm-y) dan berpartisipasi dengan bentuk lain dari antrean tugas mikro/nano/pico yang sudah ditentukan dalam spesifikasi HTML5. Artinya, jika Anda dapat meminta browser memanggil JS, Anda harus dapat memanggilnya wasm (yang sangat mungkin terjadi di MVP karena Anda hanya dapat meminta JS memanggil wasm, tetapi kami berteori tentang dunia di mana pekerja (atau bahkan utas utama) _only_ berisi wasm). (Pengecualian: Saya baik-baik saja meninggalkan event handler inline sebagai JS-only selamanya :)

Jika saya dapat menawarkan beberapa pemikiran dari sisi server (khususnya node). Ada tiga kasus penggunaan utama untuk utas (mungkin ada nama yang "tepat" untuk ini, tetapi Anda akan mendapatkan idenya):

• Pekerjaan asli yang berat secara komputasi. Ini tidak memiliki tumpukan JS. Nilai diteruskan, panggilan balik disetel, dan ketika nomor telah diurutkan, panggilan balik menerima nilai kembalian.
• Segera keluar dari utas. Satu file diteruskan, bersama dengan argumen opsional, yang berjalan hingga selesai, di mana nilai pengembalian waktu dapat dikirim kembali ke utas induk. Yang satu ini memiliki dua variasi.
  
  
  
  • Tidak ada utas akses I/O. Utas yang muncul pada dasarnya sinkron, tetapi untuk lebih membatasi lingkup pekerjaan yang dapat dilakukan oleh utas ini, mereka juga tidak diizinkan untuk melakukan operasi I/O sinkronisasi.
  
  
  • benang I/O. Diizinkan untuk meminta modul lain dan melakukan sinkronisasi I/O.
  
  
• Benang lingkaran acara. Ini pada dasarnya seperti proses yang sedang berjalan. Kecuali dalam cara mereka berkomunikasi, dan memiliki kemampuan untuk berbagi memori.

Ini memiliki variasi tentang bagaimana pengembang ingin mereka diterapkan. Seperti halnya utas yang segera keluar membuat tumpukan JS baru setiap saat, atau menggunakan yang baru. Apakah utas ditutup saat operasi selesai atau digunakan kembali. Dan juga utas, sinkron atau asinkron, bergabung menyebabkan utas utama diangkut hingga utas yang dihasilkan selesai.

Maaf jika ini terlalu banyak contoh. Apa yang saya maksud adalah sepertinya kemampuan wasm untuk bekerja dengan utas tidak akan cukup rendah atau cukup luas untuk memenuhi kebutuhan ini (saya tidak berharap itu bisa mengenai contoh pertama). Meninggalkan aplikasi server yang perlu menggunakan binding mereka sendiri. Ini benar?

Saya tidak memiliki semua jawaban, tetapi satu hal yang dapat saya komentari adalah bahwa utas WebAssembly akan memiliki akses ke API tingkat pthreads, sehingga aplikasi akan memiliki cukup banyak kontrol. Keputusan seperti kapan dan bagaimana menggunakan pthread_join sebagian besar ditentukan oleh aplikasi (atau oleh perpustakaan yang ditautkan ke aplikasi).

Selain itu, WebAssembly sendiri sedang dirancang untuk tidak bergantung pada JS, dan dimungkinkan untuk memiliki utas WebAssembly tanpa kode JS di tumpukan.

Terima kasih. Itu bagus untuk didengar.

Hal-hal apa di sini yang perlu kita putuskan untuk MVP, dan hal-hal apa yang bisa menunggu sampai kita benar-benar memperkenalkan memori bersama?

Saya tidak melihatnya secara langsung memblokir apa pun di MVP. Karena itu, untuk sesuatu yang begitu sentral, sepertinya kita harus memiliki gagasan yang cukup jelas tentang fitur tersebut (dan beberapa pengalaman eksperimental) sebelum MVP benar-benar diselesaikan/dirilis. Saya tidak melihat "blocks_binary", meskipun.

Beberapa masalah tentang WebWorkers dirinci di sini: https://github.com/lars-t-hansen/ecmascript_sharedmem/issues/2

FWIW, keduanya adalah masalah impl dan masalah yang kami harapkan untuk diatasi di FF.

@lukewagner , mereka tidak sepenuhnya masalah implementasi. Semantik startup pekerja diizinkan oleh spesifikasi pekerja. Pembatasan jumlah utas adalah konsekuensi dari keinginan untuk mencegah serangan DOS, tetapi ini sangat kasar dan sesuatu yang lebih baik, dengan observabilitas (yaitu pengecualian yang dilemparkan pada kegagalan untuk membuat pekerja), akan diterima oleh banyak aplikasi, tetapi mungkin memerlukan spek juga berubah Selain itu, sejauh yang saya tahu tidak ada cara untuk mendeteksi jika seorang pekerja telah pergi, yang merupakan lubang spesifikasi yang aneh, tetapi saya belum menemukan mekanisme untuk itu.

@lars-t-hansen Adapun pekerja yang tidak memulai sebelum kembali ke loop acara, ketika Anda mengatakan "diizinkan oleh spesifikasi", apakah maksud Anda hanya dengan spesifikasi yang tidak menentukan kapan kemajuan dibuat atau apakah itu secara khusus menyebutkan kasus ini? Adapun batasan jumlah thread, Anda benar, yang dibutuhkan (selain kuota yang lebih tinggi) adalah beberapa kesalahan yang terlihat untuk menunjukkan kuota terlampaui.

Saya pikir jaminan kemajuan-maju adalah apa yang kita inginkan di sini, sejalan dengan makalah N4439 Torvald Riegel kepada komite standar C++ .

@lukewagner , ingatan saya adalah bahwa spesifikasi tidak memiliki bahasa yang menangani kemajuan sama sekali. Awalnya saya pikir itu tidak masalah (banyak) karena itu tidak dapat diamati oleh agen pembuat tanpa agen itu menunggu suatu acara, tetapi sebenarnya tidak demikian - jika pekerja memiliki akses ke XHR atau rendering maka utas utama dapat terputus pekerja untuk memiliki efek eksternal, dan tidak adanya efek akan terlihat ke server web jarak jauh atau pengguna.

@jfbastien , saya belum membaca makalah itu tetapi saya setuju, sesuatu seperti itu diinginkan.

(Saya akan menulis ke standar Web kami orang-orang tentang spesifikasi Pekerja.)

Beberapa catatan lagi tentang pekerja. Bagian tengah adalah spesifikasi WHATWG 10.2.4, Model Pemrosesan

• Algoritme "jalankan pekerja": "1. Buat lingkungan eksekusi paralel terpisah (yaitu utas atau proses terpisah atau konstruksi setara), dan jalankan sisa langkah ini dalam konteks itu."). Ini menyiratkan cukup kuat ("paralel", "utas atau proses") bahwa seorang pekerja memerlukan konkurensi yang sebenarnya, yang melarang penundaan loop kembali ke peristiwa dan penundaan menunggu sumber daya yang tidak terbatas.
• Algoritme "bunuh pekerja" memiliki catatan menarik: "Agen pengguna dapat memanggil model pemrosesan "bunuh pekerja" pada pekerja kapan saja", yaitu, pekerja bisa mati tanpa alasan sama sekali. (Dan tidak jelas bahwa ini dapat diamati secara langsung.)

@lars-t-hansen Hah, poin bagus tentang observabilitas melalui jaringan (terutama ketika Anda memperhitungkan sinkronisasi akun XHR di utas utama) > :)

Mengenai bagian "kapan saja" "bunuh seorang pekerja", itu aneh. Saya berharap ini mengacu pada dialog skrip lambat, tetapi, jika demikian, tampaknya berguna untuk mendefinisikannya dengan lebih baik sebagai bagian dari acara aplikasi yang lebih besar yang membunuh semua pekerja dan skrip.

@lukewagner , Spesifikasi pekerja layanan (https://slightlyoff.github.io/ServiceWorker/spec/service_worker/) memberikan pembenaran minimal untuk perilaku "bunuh pekerja" (memang, kurangnya UI untuk dialog skrip yang lambat, lihat bagian "Seumur Hidup") tetapi tidak ada panduan aktual tentang cara menghindari ditembak mati. Untuk pekerja komputasi dalam konteks SAB bahwa lisensi untuk mematikan sangat merepotkan, karena mode default untuk pekerja seperti itu adalah menunggu pada variabel kondisi untuk lebih banyak pekerjaan, bukan kembali ke loop peristiwanya.

Bug diajukan terhadap spesifikasi WHATWG di sini: https://www.w3.org/Bugs/Public/show_bug.cgi?id=29039.

@slightlyoff mungkin dapat

Saya kira menjalankan webasm di lingkungan proses tunggal yang ketat akan dapat dilakukan bahkan jika spesifikasinya memerlukan kehadiran API tingkat pthreads? Karena paralelisme, sebagai lawan dari konkurensi, tidak dapat dijamin, implementasi akan bebas untuk memperlakukan "pthreads" yang dibuat sebagai blok untuk dijadwalkan secara sewenang-wenang?

Apakah ada jaminan yang lebih ketat daripada soft realtime yang dijamin oleh spesifikasi?

@emanuelpalm setuju, implementasi yang valid dapat meniru sistem prosesor tunggal.

Hard-realtime bukanlah sesuatu yang saya pikir dapat kami jamin secara umum karena WebAssembly tidak mengetahui a-priori mesin mana yang akan dijalankannya. Saya melihat batasan ini mirip dengan algoritma waktu-konstan yang menjanjikan: file .wasm tidak tahu bagaimana itu akan benar-benar diturunkan dan persisnya jaminan apa yang dapat diharapkan dari JIT dan mesin yang akan dijalankannya.

Saya sangat bersemangat tentang ini:
http://images.nvidia.com/events/sc15/SC5105-open-source-cuda-compiler.html
https://developer.nvidia.com/CUDA-LLVM-Compiler

Adakah pemikiran jika menerapkan loop paralel forall akan layak di Majelis Web?

Seperti apa saluran pipa itu sebagai cara konkret untuk bereksperimen?
web assembly -> wasm binary -> chrome -> gpu

Tampaknya lebih nyaman untuk memiliki sesuatu seperti:
web assembly -> binary (jit?) -> chrome -> gpu

@jbondc Saya pikir pemikiran Anda lebih dekat dengan paralelisme C++ TS, yang membutuhkan dukungan runtime. Itu mungkin, tetapi WebAssembly saat ini tidak memiliki pekerjaan berkelanjutan untuk GPU. Ini penting, tetapi bukan fokus utama untuk MVP. Pekerjaan oleh tim Robert sangat berbeda dari apa yang akan dilakukan WebAssembly (meskipun dapat mengambil manfaat dari pekerjaan itu).

Ya ini terlihat benar:
https://github.com/cplusplus/parallelism-ts/blob/master/parallelism-ts.pdf

Tetapi lebih tertarik untuk menulis bahasa saya sendiri yang dikompilasi ke Majelis Web (dan memiliki dukungan paralelisme).

Saya pikir hal terbaik yang dapat dan harus dilakukan adalah menyediakan primitif perangkat keras mentah untuk paralelisme ( utas dan SIMD ) dalam model CPU tujuan umum yang diasumsikan oleh WebAssembly ke Web yang Dapat Diperluas .) Berdasarkan ini, saya akan berpikir perpustakaan dalam paralelisme C++ TS akan disediakan sebagai perpustakaan di atas primitif platform web yang disebutkan di atas, bukan sebagai fungsi bawaan (setidaknya, tidak dalam waktu dekat).

Pikiran tentang sesuatu seperti ini:
http://www.actor-framework.org/pdf/manual.pdf
https://github.com/actor-framework/actor-framework
https://www.youtube.com/watch?v=VOFOj3LLXRk

Apakah ini cerita yang mungkin?

@jbondc Ini adalah abstraksi tingkat yang lebih tinggi dan kerangka kerja yang saya harapkan dapat diimplementasikan dalam wasm dengan kinerja yang baik. Jika seseorang mencoba mem-porting ini dan menemukan beberapa penghenti acara, maka ini mungkin menyarankan dukungan threading tingkat rendah ekstra untuk dipertimbangkan untuk wasm?

Pemahaman saya di balik alasan untuk menghindari abstraksi tingkat tinggi seperti itu adalah bahwa mereka umumnya memiliki kegunaan khusus dan juga mereka memiliki asumsi dan batasan yang melekat yang tidak memetakan dengan baik ke perangkat keras, jadi mungkin tidak ada kepentingan umum untuk menjamin dukungan langsung tetapi mungkin seseorang dapat mengumpulkan dukungan untuk beberapa model komputasi paralel lainnya.

Ini bukan abstraksi tingkat yang lebih tinggi. "Model Aktor" (https://en.wikipedia.org/wiki/Actor_model) adalah model teoretis yang berbeda untuk dipikirkan tentang komputasi (vs. mesin turing terbatas).

Berdasarkan perangkat keras (misalnya gpu oleh Nvidia), Anda dapat mengimplementasikan dalam VM beberapa pesan yang melewati hal yang mirip aktor. Cara saya melihatnya, jika Chrome, Chakra, Firefox atau Webkit akan menerapkan pencocokan pola + hal yang disukai aktor, maka kita akan mendapatkan paralelisme C++ secara gratis, berbagi memori + utas, dan hampir semua model bersamaan lainnya.

Terkait jika seseorang ingin meretas sesuatu bersama-sama:
https://github.com/solodon4/Mach7

@jbondc Ini bukan SMP dan diragukan bisa mengimplementasikan kode SMP dengan tingkat efisiensi apa pun? Pertimbangkan bagaimana itu akan mengimplementasikan tumpukan dan antrian dan cache yang diperbarui secara atom dll dalam kode yang ditulis untuk memori bersama? Dukungan wasm yang direncanakan harus memungkinkan beberapa bahasa pemrograman 'Model Aktor' ini diimplementasikan dalam wasm, dan operasi atom dapat digunakan untuk mengimplementasikan antrian pesan cepat dan manajemen memori untuk memisahkan aktor, dll.

@JSStats Saya lebih mencoba melihat blok bangunan yang bagus. Perangkat keras yang lebih baik sudah ada di sini.

Ada diskusi bagus tentang perangkat keras di sini:
http://amturing.acm.org/acm_tcc_webcasts.cfm (Arsitektur Komputer)

Utas/desain memori bersama buruk.
Actor Model Hewitt atau beberapa variasinya adalah cara yang tepat.

Sebagai contoh konkret, ini adalah pekerjaan yang baik:
http://2014.rtss.org/wp-content/uploads/2014/12/RTSS2014-sifakis-distr.pdf

Halaman 34. Utas buruk.
Halaman 48. Model yang bagus.

Halaman 59-60. Sebuah ~'binary jit' dapat diterapkan di sini: Generator BIP terdistribusi.

Saya akan mencoba beberapa eksperimen dalam beberapa bulan mendatang, semoga yang lain akan bergabung.

Memindahkan milestone ini ke Post-MVP, sehingga milestone MVP berfokus pada tugas yang dapat ditindaklanjuti untuk MVP. Jelas penting untuk merencanakan utas, tetapi menurut saya sudah ada kesadaran yang cukup, jadi kami tidak perlu masalah ini untuk mengingatkan kami. Jika orang tidak setuju, saya baik-baik saja memindahkannya kembali.

@jbondc Jika Anda berencana untuk melakukan beberapa eksperimen, silakan buka edisi baru untuk melaporkan temuan Anda. Terima kasih!

@sunfishcode Akan melakukannya, tetapi sebagian besar menyerah.

Bagi siapa saja yang tertarik dengan BIP:
http://www-verimag.imag.fr/New-BIP-tools.html

Apakah pemikirannya dengan utas WASM, kode seperti ini akan dikompilasi menjadi operasi pemuatan/penyimpanan atom?

class FastBlockableMutex {
 protected:
  atomic<bool> mIsLocked;
  atomic<int> mWaiters;
  atomic<int> mBlockers;
  mutex mMutex;

};

@jbondc itu akan membutuhkan instruksi untuk menurunkan ke ops ;-)
Ya, akses atom akan selama ukurannya bebas kunci. Mutex kemungkinan akan pergi ke atom dan kemudian beberapa hal seperti futex. Saya berharap modelnya mendekati ini .

@jbondc bukankah ide untuk menyediakan utas dan membandingkan-dan-swap dll sehingga seseorang dapat membangun implementasi aktor bebas kunci di atasnya?

@malthe Ya, setelah beberapa penelitian, itulah yang dilakukan ponylang:
https://github.com/ponylang/ponyc/blob/master/src/libponyrt/actor/actor.c
https://github.com/ponylang/ponyc/blob/master/src/common/pony/detail/atomics.h

Ada juga beberapa pola paralelisme yang menarik dengan HPX:
https://www.youtube.com/watch?v=6Z3_qaFYF84&feature=youtu.be&t=16m1s
https://github.com/STEllAR-GROUP/hpx/tree/master/external/atomic/boost/atomic/detail

Dan kemudian pemrograman GPU:
https://www.youtube.com/watch?v=KHa-OSrZPGo
https://github.com/ponylang/ponyc/issues/1330
http://llvm.org/docs/NVPTXUsage.html

@binji akan membahas proposal utas . Penutupan.