Design: pThreads irgendwelche ETA ?

Irgendwann in den nächsten paar Quartalen ist wahrscheinlich so genau, wie man sagen kann. Bitte reservieren Sie den Issue-Tracker jedoch zum Melden von Issues.

Dieses Projekt hat keine Mailingliste oder ein anderes Forum, daher ist der Issue-Tracker der einzige Ort, an dem Leute Fragen zum Designprozess stellen können. Es ist wertvoll, einen Ort zu haben, an dem Leute Fragen stellen können, daher ermutige ich die Leute, weiterhin den Issue-Tracker zu verwenden, um Fragen zu stellen.

@sunfishcode , fair genug, aber dann schlage ich vor, dass wir eine solche Liste erstellen. Ich glaube nicht, dass ein Issue-Tracker ein geeigneter Ersatz dafür ist.

Es gibt die öffentliche w3-Liste . Es ist jedoch nicht sehr stark befahren. Es gibt auch ein IRC, glaube ich? Ich denke, es war irgendwann auf der Website, aber es wäre schön, wenn beide direkt im Community-Bereich der Website verlinkt wären. Ich würde ein Thema eröffnen, aber ich bin mir nicht sicher, welche Wege Sie alle lieber ~offenbart~ mit der Öffentlichkeit verknüpft sehen würden

Anleitung hier:

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

Wir haben die Leute angeleitet, github zu verwenden. Nicht jeder mag es, aber es ist besser, einen Ort zu haben als viele.

Hallo @rossberg-chromium und danke für deine zeitnahe Antwort.

Bitte reservieren Sie den Issue-Tracker jedoch zum Melden von Issues.

Wie von @jfbastien betont , habe ich hier gefragt, weil es der beste Ort zu sein scheint, um dies auf standardmäßige Weise zu tun.
Außerdem ist die Thread-Unterstützung ein Designfeature, das für webAssembly entscheidend ist.
Mehr als der Logo-Kontext und "Warum ist es nicht in Java implementiert" sehe ich als Probleme aufgeworfen.

Wenn ich falsch liege, sagen Sie mir bitte, wo ich der Shared Memory / Thread-Implementierung folgen soll.
Es sollte ein offener Prozess sein, also möchte ich meine Meinung sagen.

--R

@RobertoMalatesta Wir sind uns einig, dass Threads sehr wichtig sind, aber es war wichtiger , sie richtig zu machen, als sie in das minimal funktionsfähige Produkt von WebAssembly zu stopfen. Unsere Argumentation ist einfach: asm.js war ohne diese Funktion erfolgreich.

Threads sind definitiv ein Make-or-Break-Feature für einige wichtige Anwendungen, aber nicht für alle Anwendungen. Dasselbe gilt für GC, kostenlose Ausnahmebehandlung, garantierte Rückrufe usw.

Die Entscheidung, ein MVP zu machen, bedeutet, dass wir nicht alle beim ersten Start glücklich machen. Es bedeutet auch, dass einige Leute WebAssembly überhaupt verwenden können, bevor wir alles entworfen, spezifiziert und implementiert haben.

Davon abgesehen erwarten wir, dass wir den JavaScript SharedArrayBuffer -Ansatz mehr oder weniger in WebAssembly übernehmen werden. Viele von uns waren von Anfang an mit dieser Spezifikation beschäftigt. Es würde Low-Level-Funktionen hinzufügen, die denen von C++ ähneln, plus eine Futex-ähnliche API. Es hat Raum zum Wachsen mit mehr Speicherordnungen als bei sequentieller Konsistenz. Es wird laufend daran gearbeitet, ein formelles Speichermodell dafür zu erstellen.

SAB befindet sich in TC39 in „Stufe 4“, was bedeutet, dass es fertig, versandbereit und einsatzbereit ist. Ich gehe davon aus, dass die Übernahme in WebAssembly nicht allzu schwierig sein wird.

@jfbastien danke für die aufschlussreichen Infos.

Davon abgesehen erwarten wir, dass wir den JavaScript SharedArrayBuffer-Ansatz mehr oder weniger in WebAssembly übernehmen werden.(...)
SAB befindet sich in TC39 in „Stufe 4“, was bedeutet, dass es fertig, versandbereit und einsatzbereit ist. Ich gehe davon aus, dass die Übernahme in WebAssembly nicht allzu schwierig sein wird.

Toll. Ich bin bestrebt, es mit einer Menge C++-Code zu ermüden, der einfach nach Threading hungert.
Ich verwende regelmäßig WebWorkers in meinen TS/JS-Anwendungen und ich muss sagen, dass ich kein Fan von ihnen bin, aber sie könnten als erster Anfang gehen.

Threads sind sehr wichtig, aber es war wichtiger, sie richtig zu machen, als sie in das minimal funktionsfähige Produkt von WebAssembly zu stopfen. Unsere Argumentation ist einfach: asm.js war ohne diese Funktion erfolgreich.

Verstehen Sie die Notwendigkeit eines MVP, um schnell aussteigen zu können (ich denke, das war der Grund, AST fallen zu lassen, um Stack-basiert zu werden) und die Sorgfalt, die es braucht, um weitere Schritte zu planen.

Threads sind definitiv ein Make-or-Break-Feature für einige wichtige Anwendungen, aber nicht für alle Anwendungen. Dasselbe gilt für GC, kostenlose Ausnahmebehandlung, garantierte Rückrufe usw.

Als langjähriger Benutzer von emscripten würde ich gerne sehen, dass WebAssembly stärker von den Stack-Limits von Javascript-Anwendungen entkoppelt ist:

Wasm sollte nur 1) auf höchste Leistung abzielen und 2) Sockets, Speicher/Threads, GDI, fs mit einem gewissen Posix/Unix/BSD-Standard bereitstellen. Auf diese Weise wäre es eine dünne OS-ähnliche Schicht, die sowohl in mobile Geräte als einheitliche Zielplattform als auch in Server eingebettet werden kann, um um Cloud-bereitstellbare Anwendungen zu konkurrieren.

Ist dies die Richtung, in die Wasm in eine langfristige Zukunft geht, oder verpasse ich völlig den Anschluss?

Nochmals vielen Dank für Ihre Arbeit,

Roberto

Wasm ist definitiv von einigen Stack-Limits entkoppelt, weil wir die Locals von dem trennen, was ein Compiler wie LLVM in den für den Benutzer zugänglichen Speicher einfügen muss.

Mit Threads, insbesondere wenn sie nicht Worker-basiert sind, erhalten Sie dort mehr Leistung.

Davon abgesehen wäre es gut, mehr Details zu Ihren genauen Vorstellungen zu erfahren. Was ist der Anwendungsfall, wie umgehen Sie ihn in C++ und wie würden Wasm-Implementierungen das tun?

Ich erwarte nicht, dass Sie alle Antworten finden! Was mir jetzt noch einfällt. Fwiw C++ hat einige Vorschläge für Stack-Limits. Schauen Sie sich die SG14-Untergruppe an.

Entschuldigung für die niedrigen Details, ich stehe unter einem 👶🌯. Werde später besser antworten!

Entschuldigung für die niedrigen Details, ich bin unter einem :baby:: burrito:. Werde später besser antworten!

Du bist unter einem Baby-Burrito? Lol

@qwertie

Du bist unter einem Baby-Burrito? Lol

Im wahrsten Sinne des Wortes ein eingewickeltes Baby.

Hallo @jfbastien ,

Es wäre gut, mehr Details zu Ihren genauen Vorstellungen zu erfahren. Was ist der Anwendungsfall, wie umgehen Sie ihn in C++ und wie würden Wasm-Implementierungen das tun?

Im Allgemeinen ist mein Anwendungsfall das Erstellen von Simulationssoftware, wobei die Grenze im Rechenteil nur die Maschine ist, dank C++, C/OpenCL und GPUs-Technologien.

Auf dem Front-End hat sich der Stack HTML5+CSS+Javascript+Typescript als gültige, erprobte und tragbare Methode zur Entwicklung mittelgroßer komplexer Anwendungen erwiesen.

_ D er JS Web Stack (mit dem Zusatz einer strukturierten Sprache wie Typescript) ist heutzutage so gut, dass ich nicht das Bedürfnis verspüre, für die meisten Anwendungen auf emscripten zurückzugreifen oder wasm auszuprobieren._

Ich stimme den High Level Goals und den Webassembly Use Cases fast vollständig zu und noch mehr dem Non-Web Embeddings Document .

_ WebAssembly wird (zumindest für mich) eine relevante Technologie sein, wenn sie es ermöglicht, schneller zu sein (bis zum Knochen einer nativen C-App plus, sagen wir 5% Overhead), mehr Speicher zu nutzen und freier zu sein, Ports/Sockets vollständig implementiert zu haben und erlauben, Threads wie jedes normale Betriebssystem auszuführen._

Eine Wasm-Maschine sollte sehr geschickt in der Größe, schnell und vorausschauend sein, also stecken Sie bitte keinen GC hinein: GCs sind das Ponzi-Schema der IT: Sie machen Schulden und kümmern sich nicht um die Zuweisung, bis es zu spät ist und Sie Zyklen verlieren . Wenn wir außerdem eine superleistungsfähige Wasm-Core-Maschine haben, kann ein GC darauf gebaut werden.

Der Einfachheit halber würde ich es schrittweise von Javascript lösen. Wenn ich native Compiler in irgendeiner Sprache habe, brauche ich kein Scripting und trotzdem könnte ich ein Duktape/Lua/was auch immer einbetten, indem ich einfach in die C-Quellen kompiliere.

Irgendwo auf der Mozilla-Site habe ich Dokumente zur Implementierung von wasm-nativer DOM-Manipulation gesehen: Ich denke nicht, dass es sehr nützlich sein wird, da die DOM-Manipulation von Natur aus sequentiell ist und einer der zeitaufwändigsten Aspekte des HTML5/CSS/JS-Stacks ist: if Ich schreibe superschnelles Multithread-Wasm, nur damit meine DOM-Änderungen serialisiert in der Warteschlange warten, dann ist die gesamte Leistung weg und es ist besser, etwas Typoskript zu transpilieren, als C/C++ zu verwenden. In diesem Fall würde ich den direkten OpenGL-Zugriff bevorzugen (zuerst mit einer WebGL-Implementierung, dann OpenGL-nativ). Der Zugriff auf die Grafikkarte wird sich als nützlich erweisen, um GPU/CUDA-Funktionen mit geringem oder keinem Overhead anzubieten.
(Ich habe das gerade überprüft und habe Ausgabe Nr. 273 erhalten, die sich damit befasst.)

Eine winzige WASM-Maschine zu haben, die von allen Anbietern und Unabhängigen gemeinsam genutzt wird, könnte den Alptraum der mobilen Entwicklung lösen, bei der Sie mindestens 4 Toolchains für verschiedene Betriebssysteme und Versionen und Architekturen haben.
Grafik- und Eingabemöglichkeiten könnten variieren, aber wir könnten uns zu einem Wasm entwickeln und dann die APIs der Einrichtungen abfragen oder sogar dieselbe Anwendung in verschiedenen App-Stores bereitstellen.
Langfristig: Dasselbe gilt für Serveranwendungen, das Erreichen einer Art Konsens über Einrichtungen (DB-Verbindungsprotokolle und -pools, Gelbe-Seiten-Systeme, Messaging-Protokolle und -Systeme usw.) und das Packen dieser in eine Standardspezifikation, wie es die JEE-Plattform tat. (Ein Großteil der konzeptionellen Arbeit wurde bereits in den letzten 20 Jahren angelegt).

Ich erwarte nicht, dass Sie alle Antworten finden! Was mir jetzt noch einfällt. Fwiw C++ hat einige Vorschläge für Stack-Limits. Schauen Sie sich die SG14-Untergruppe an.

Sicher werde ich tun.

Vielen Dank für Ihre Geduld und Zeit.

rauben

Als kleine Ergänzung wäre es bei der Implementierung von Threads toll, wenn die Stackgröße beliebig groß gemacht werden könnte, oder stattdessen auf mindestens 64MB gesetzt werden könnte. Dies liegt daran, dass mein Anwendungsfall eine Anwendung ist, die 2 Threads verwendet, und der Nicht-Hauptthread einen ziemlich großen Stack benötigt.

@jjpe , das wäre eine Anfrage für eine bestimmte Toolchain (z. B. emscripten), die auf wasm abzielt, und nicht auf dieses Repo, da es eher um die Wahl der Implementierung oder ABI einer Toolchain geht als um etwas über die wasm-Plattform an sich. (Sie könnten also z. B. ein Problem auf https://github.com/kripken/emscripten/ eröffnen)

Einige der Dinge, die ich in meiner früheren Botschaft vorgeschlagen habe, scheinen im neuesten WASI-Vorschlag enthalten zu sein.
Sehen:
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

Daumen drückend.

--R

FWIW Der aktuelle Status ist, dass Chrome Wasm-Threads-Unterstützung in Version 74 ausliefert, Firefox eine Implementierung hat, die noch nicht ausgeliefert wurde, und Emscripten PThreads-Unterstützung (https://emscripten.org/docs/porting/pthreads.html) mitbringt war jetzt verfügbar.

(Auch WASI ist eine Systemaufruf-API, die meistens orthogonal dazu ist, ob eine bestimmte Wasm-Einbettung oder Toolchain Threads/Atomics unterstützt oder nicht).

Gibt es Dokumente zur Verwendung von Chrome- und Firefox-Thread-APIs?

Es ist eine Art Kombination von Dingen. Die wasm-Engine des Browsers implementiert die threads/atomics-Erweiterung der wasm-Spezifikation (https://github.com/WebAssembly/threads/tree/master/proposals/threads), die es ermöglicht, gemeinsam genutzte wasm-Speicher zu instanziieren. Im Web können Sie einen Web-Worker erstellen und den Speicher (und alle zugehörigen WASM-Module) per postMessage an den Worker senden. Dann instanziieren Sie das Modul mit dem gemeinsam genutzten Speicher auf dem Worker (und auf dem Haupt-Thread oder einem anderen Worker) und die Instanzen teilen sich ihren Speicher. Die Übersicht über Spezifikationsvorschläge (https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md) enthält ein kleines Beispiel, andere sind mir nicht bekannt.

Hallo @dschuff und danke für die obige Antwort.
In meiner früheren Nachricht bezog ich mich auf eine frühere, die nicht nur pthreads beinhaltete, sondern eine wünschenswerte Weiterentwicklung von wasm zu etwas mehr Kernel-ähnlichem, was einige von uns, die emscripten seit 2010 verfolgen und verwenden, damals als eine echte bahnbrechende Technologie betrachteten.
Siehe: https://github.com/WebAssembly/design/issues/992#issuecomment -285055578 .

Neun Jahre nach dem Erscheinen von Emscripten und fast fünf Jahre nach der Ankündigung von Wasm wurden bei der Umwandlung von Wasm in eine brauchbare Servertechnologie nur wenige Fortschritte erzielt.

Leider, weil wir einen Standard für portable Apps brauchen, und der beste Weg, dies zu tun, wäre meiner Meinung nach gewesen, einen winzigen Kernel (BSD/Linux-ähnlich) mit POSIX-Threads und Berkeley Sockets + ein in sich geschlossenes sicheres virtuelles Dateisystem (mit Benutzern) zu implementieren und Gruppen genügen). Ich halte an dem alten Spruch von H. Spencer fest: "Diejenigen, die UNIX nicht verstehen, sind dazu verdammt, es neu zu erfinden".

Ich möchte immer noch glauben, also ist WASI ein Schritt in die richtige Richtung.

--R

PS: 2010 emscripten rockt immer noch, da es im unsterblichen Browser funktioniert, dem unsäglichen Untötbaren, der in den meisten Unternehmen verwendet wird und der die Leichen von Firefox und Safari vorbeiziehen sehen wird (zumindest ihre Engines).