Worker threads not implemented for IOS (--experimental-worker)

[dmdeklerk]

-- Changed the title of this issue from How to pass flags to node process (--experimental-worker)

The MicroService.start method mentions you can pass arguments that will be appended to the node process.
But what about flags https://nodejs.org/api/cli.html more specifically how would I pass --experimental-worker to the node process?
https://nodejs.org/docs/latest-v10.x/api/worker_threads.html#worker_threads_worker_threads

[dmdeklerk]

This seems to work on Android

android.system.Os.setenv("NODE_OPTIONS", "--experimental-worker", true)
val uri = MicroService.Bundle(ctx, "index")
service = MicroService(ctx, uri, startListener)
service.start()

On IOS in swift this works

setenv("NODE_OPTIONS", "--experimental-worker", 1)

[dmdeklerk]

As we are doing lots of crypto operations doing so on LiquidCore Android turned out to run approx 5 to 10 times slower than LC on ios. Now after refactoring the nodejs code and running in worker_threads we got an instant boost of approx 20x speedup making things acceptable.

Unfortunately LiquidCore crashes here https://github.com/LiquidPlayer/LiquidCore/blob/master/LiquidCore/src/ios/V82JSC/Isolate.cpp#L685 when trying to use worker_threads on ios.

No idea yet how to tackle this and looking for help in enabling worker_threads for LiquidCore.

Thanks

[dmdeklerk]

Updated the title of this issue.

A short note on how worker_threads could considerably speedup overall performance of Liquid-core based projects.

First off we are using the LC microservice and have setup an event based communication protocol where the
Android or IOS host (Flutter in our case) dispatches an event to the microservice and the microservice has a range
of methods indexed by their unique ID's, now based on the event contents we invoke the correct code through LiquidCore
and send back the result as an event emitted to the LiquidCore host (our flutter app).

Refactoring this setup to use worker threads - what we did was run this code through the bundler tool and use another script to wrap that output in a global variable as a string (so the bundler output is what we run in the workers). Now you can create workers based on having that source code available as a string and communicate with those workers after setting up a pool mechanism and a job queue, we use 10 workers in our case.

In the end all our javascript implementations stayed as is, as do all of our tests as well as all the Flutter code that acts as bridge code.
The speedup however of having these 10 worker threads available is considerable to the point where Android outperforms IOS when it comes to cpu heavy computations.

[dmdeklerk]

worker_threads over JavascriptCore seems impossible as it lacks v8 isolates https://v8docs.nodesource.com/node-0.8/d5/dda/classv8_1_1_isolate.html

On Android however they work and can give a considerable speed ups.