Andy Wermke

Hmm, that's weird. threads.js subscribes to messages that the main thread receives from the worker via a `.addEventListener("message", handler)` call. What's weird is that it normally only subscribes once to...

Thanks a lot, @Patbox! Still so weird, though… It happens while only one spawning once, it seems. And I can run all the tests with node 12.6.3 and get no...

Ahh, I see the issue now. You run into this message if you call a worker thread in rapid succession. ### The issue Every call to the worker thread leads...

Haven't found time to work on that yet, but it's good to know that there is interest in that 👍

Interesting point. Haven't tried anything alike, nor am I aware of anyone else using threads.js with react-native. I think you might be able to use threads.js with [react-native-threads](https://github.com/joltup/react-native-threads) like this...

We could look into supporting react-native if it's just a few simple changes. Can you try to disable the line that does the `expose() called in the master thread.` check?...

Can you try to polyfill the `*EventListener` methods on the worker, similar to this? https://github.com/andywer/threads.js/blob/master/src/master/implementation.node.ts#L199-L210 As you can see we had the same situation with the tiny-worker in the beginning...

Thanks, @Slapbox! The polyfill… The web worker spec only requires the `Worker` to support an `onmessage` and an `onerror` property, both callback functions. Those are plenty inconvenient to use once...

Thanks for sharing the update! :) If you want, you can take it one step further and wrap the `worker.postMessage()` method, use a package like [flatted](https://www.npmjs.com/package/flatted), serialize all data passed...

PS: I would be happy to integrate these fixes as a dedicated react-native backend and make it part of the core package if the serialization fix does the trick.