openfl
Add asynchronous worker support for the HTML5 target
BackgroundWorker as well as ThreadPool use a synchronous mode on HTML5, but these could be made to use web workers on HTML5
https://stackoverflow.com/a/37156020
Depending on the performance of web workers, it may be preferable to consider whether one or both of the above APIs should also have a way to use them synchronously by choice, if web workers end up being too expensive
ThreadPool won't work in HTML5, because you can't pass functions as a message. This behavior is required by Future at the very least.
(Yeah, I know only Firefox uses the structuredClone() function, but the error also happens in Chrome, so whatever function it uses imposes the same restriction.)
Maybe we can pass a string and then call Function()...
HTML5 workers does not support shared memory usage. I know that it is possible to send byte data only with SharedArrayBuffer (or native types (integer, string, boolean, etc)).
Note: wasm has thread support but unfortunately does not share memory like worker.
Oh yeah, forgot to mention that, but the lack of shared memory is the other problem with ThreadPool. The current implementation relies on a shared Deque - the main thread adds a task to this queue, and whichever thread becomes available next gets to handle it.
Workaround is obvious but annoying: the main thread will have to handle all scheduling. Keep track of which threads are busy and which are done, and assign incoming tasks to available threads.
After significant work, I've concluded that web workers are incompatible with Lime's mission. (Long post, so click here if you just care about the reasoning.)
As an alternative, I propose a single-threaded async mode. Details to come.