As noted in issue #1, all web browsers are disabling the JS SharedArrayBuffer api as a mitigation against the Meltdown and Specter security issues. That prevents this project from working, because it relies on SharedArrayBuffer to synchronously pass data between the TADS process (running in a web worker) and the user interface (in the browser window).
The core of the problem is that JS's main way to pass data back and forth to a web worker, is via the JS event system. In the browser, you do postMessage(), which sends a message event to the web worker, and that tells JS to invoke the onmessage eventhandler method in the web worker (if it's registered).
Where it breaks down for us, is that JS is asynchronous but single-threaded. Even if an onmessage handler is registered in the web worker, it won't actually be executed until any currently-executing methods in the web worker exit. And the tadsr program, as transpiled by emscripten, doesn't exit until the program quits.
We're not the first to encounter this problem. See:
None of these are easy to do, however. As noted in the readme, Emterpreter and ASYNCIFY have already been tried. And the emscripten async functions would require a major rewrite of the plygo() method in tads2/ply.c and related I/O functions.
As noted in issue #1, all web browsers are disabling the JS SharedArrayBuffer api as a mitigation against the Meltdown and Specter security issues. That prevents this project from working, because it relies on SharedArrayBuffer to synchronously pass data between the TADS process (running in a web worker) and the user interface (in the browser window).
The core of the problem is that JS's main way to pass data back and forth to a web worker, is via the JS event system. In the browser, you do
postMessage()
, which sends amessage
event to the web worker, and that tells JS to invoke theonmessage
eventhandler method in the web worker (if it's registered).Where it breaks down for us, is that JS is asynchronous but single-threaded. Even if an
onmessage
handler is registered in the web worker, it won't actually be executed until any currently-executing methods in the web worker exit. And thetadsr
program, as transpiled by emscripten, doesn't exit until the program quits.We're not the first to encounter this problem. See:
The apparent solutions available are:
SharedArrayBuffer (not any more)ASYNCIFY
, which Emterpreter replacedInvoking tadsr as a JS generator methodyield
.tads2/ply.c
to use Emscripten'semscripten_set_main_loop()
and/oremscripten_async_call()
None of these are easy to do, however. As noted in the readme, Emterpreter and ASYNCIFY have already been tried. And the emscripten async functions would require a major rewrite of the
plygo()
method intads2/ply.c
and related I/O functions.