3 ms·

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 infini

by 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.