3 ms·

So let's say I have a web assembly binary squirreled away in a web worker or AudioWorklet. If that binary is supposed to have its own event loop, how do I achi

So let's say I have a web assembly binary squirreled away in a web worker or AudioWorklet. If that binary is supposed to have its own event loop, how do I achieve that? Seems like I'd have to hook back into the JS event loop, at which point my poor binary becomes subject to all the DOM blockers I was trying to avoid in the first place... :(

hokus 8y ago
There is a "white man can't dance" joke inthere but I cant think of it right now.
digitaLandscape 8y ago
The `WorkerGlobalScope` interface extends the `WindowTimers` interface, so you can still use `setTimeout` or `setInterval` in your workers.
Lerc 8y ago
The communication between worker and Host script is through postmessage. So yes you are just moving the event pump to a onmessage pump. If you have an infinite loop in a worker it will run fine, you just can't ever tell it anything, rendering it somewhat pointless. What is really needed is the ability to preempt/resume javascript in workers. You could fudge that with a preprocessor script that inserted, at judicious points, polling of a pseudo-interrupt flag. You'd have to use a SharedArrayBuffer which you can't have because it got disabled post-spectre. Unfortunately, I fear any mechanism that works properly would let you do things precisely and well and would consequently be blocked as a possible avenue for spectre.
- jancsika 8y ago
  The only possibility I see currently is to just slave the main loop to the AudioWorklet processing callback and blindly hope that it is able to hit the scheduling deadlines. The current native app (say, in Linux) has both a scripting language and a DSP "dataflowy" language that can run and interact in the same process. This means the user can manually (or programmatically) turn on DSP processing opportunistically. However, with the Web Audio idea above this means that the software I'm porting must be calculating its DSP graph from the AudioWorklet callback at all times for the software to work at all. If I suspend audio computation in the parent script time would no longer move forward. Or I'd have to switch to having the DOM poll the worker-- feeding it the current time-- which I'm just guessing would kill performance.

hokus 8y ago

There is a "white man can't dance" joke inthere but I cant think of it right now.

digitaLandscape 8y ago

The `WorkerGlobalScope` interface extends the `WindowTimers` interface, so you can still use `setTimeout` or `setInterval` in your workers.

Lerc 8y ago

The communication between worker and Host script is through postmessage. So yes you are just moving the event pump to a onmessage pump. If you have an infinite loop in a worker it will run fine, you just can't ever tell it anything, rendering it somewhat pointless. What is really needed is the ability to preempt/resume javascript in workers. You could fudge that with a preprocessor script that inserted, at judicious points, polling of a pseudo-interrupt flag. You'd have to use a SharedArrayBuffer which you can't have because it got disabled post-spectre. Unfortunately, I fear any mechanism that works properly would let you do things precisely and well and would consequently be blocked as a possible avenue for spectre.

jancsika 8y ago
The only possibility I see currently is to just slave the main loop to the AudioWorklet processing callback and blindly hope that it is able to hit the scheduling deadlines. The current native app (say, in Linux) has both a scripting language and a DSP "dataflowy" language that can run and interact in the same process. This means the user can manually (or programmatically) turn on DSP processing opportunistically. However, with the Web Audio idea above this means that the software I'm porting must be calculating its DSP graph from the AudioWorklet callback at all times for the software to work at all. If I suspend audio computation in the parent script time would no longer move forward. Or I'd have to switch to having the DOM poll the worker-- feeding it the current time-- which I'm just guessing would kill performance.