README.md

react-native-multithreading

🧵 Fast and easy multithreading for React Native using JSI. 🧵

⚠️ Note: This is a proof of concept.
Do not use this library in production.

VisionCamera goes beyond this concept and
use a separate JS runtime to provide an API for processing
camera frames in realtime. Check out Frame Processors!

Installation

npm install react-native-multithreading
npx pod-install

Since JSI is not officially released, installing react-native-multithreading requires you to edit a few native files. See the setup guide (SETUP.md) for more details.

Requires react-native-reanimated 2.1.0 or higher.

🎉 v1.0 with Android support is here! 🎉

Why

Since JSI is becoming more mainstream, there might be functions that are actually blocking and take a while to execute. For example, a storage library like my react-native-mmkv or an SQLite JSI library might take a few milliseconds to execute a complex call. You don't want your entire React-JS thread to freeze when doing that, since users will perceive a noticeable lag or freeze.

That's where react-native-multithreading comes in; you can simply off-load such expensive calculations/blocking calls to a separate thread with almost no overhead while your main React-JS thread can concentrate on running your app's business logic, respond to user input, update state and more. You can also run complex JS calculations such as the Fibonacci number, but that's probably a rare use-case.

Inspired by @karol-bisztyga's Multithreading PR for Reanimated

Usage

To try out the Fibonacci Example, clone the repo and run the following commands:

yarn bootstrap
cd example
yarn ios

See my tweet 🐦

Shoot and Forget

To simply perform an expensive calculation on another thread without caring about the result, use the spawnThread function:

// JS thread
spawnThread(() => {
  'worklet'
  // custom thread
  // expensive calculation
})
// JS thread

The React-JS Thread will continue execution while the custom thread will run the given function on a custom parallel runtime.

Await

Since spawnThread returns a Promise, you can also await the result. The React-JS Thread will not be blocked and will still be able to continue execution elsewhere (timers, callbacks, rendering, ...), while the custom thread runs the given function in a custom parallel runtime.

const result = await spawnThread(() => {
  'worklet'
  // expensive calculation
  return ...
})

Fibonacci

This example calculates the Fibonacci Number for the given input. This demonstrates expensive calculation, awaiting the result, as well as using values from "outside". (fibonacci function and input are captured into the new thread and therefore immutable.)

const fibonacci = (num: number): number => {
  'worklet'
  if (num <= 1) return 1
  return fibonacci(num - 1) + fibonacci(num - 2)
}

const input = 50
const result = await spawnThread(() => {
  'worklet'
  console.log(`calculating fibonacci for input: ${input} in JS-Runtime: ${global._LABEL}...`)
  const fib = fibonacci(input)
  console.log("finished calculating fibonacci!")
  return fib
})
console.log(`Fibonacci Result: ${result}`)

What's possible?

• You can run any JavaScript code you want in there.
• You can use variables from "outside" (e.g. state), but those will be immutable/frozen.
• You can use functions from "outside".
  • Worklets (functions with the 'worklet' directive) can be called directly on the separate thread
  • Native JSI functions ("host functions", aka functions that print function f() { [native code] } when you call .toString() on them) can be called synchronously (e.g. functions from react-native-mmkv)
  • Normal JS functions (e.g. setState) can be called on the React-JS thread with runOnJS
• You can assign Reanimated Shared Values.

Note that react-native-multithreading is more of a proof of concept than a production ready library. Everything works as I listed it here, but in real world app you most likely won't be needing a JS multithreading library.

What's not possible?

1. Since the library uses JSI for synchronous native methods access, remote debugging (e.g. with Chrome) is no longer possible. Instead, you should use Flipper.
2. All functions you are calling inside a custom thread, must be workletized to truly run on a separate thread. So add the 'worklet' directive at the top of every function you're calling in that thread (including the thread callback itself), and don't forget to install the Reanimated babel plugin.

Supported JS engines

• JavaScript Core (JSC)
• Hermes
• V8 (iOS only)

Performance

Since the worklets are completely dispatched in an isolated thread, nothing interrupts their execution.

Be aware that there always will be a small overhead when calling spawnThread, because all variables from outside have to be copied into the new thread first. For example, if you use the separate thread to do complex array operations, be aware that the array has to be copied into the separate thread first. Always benchmark the performance differences!

Credits

• react-native-reanimated for Shared Value adapting, essentially allowing JSI multithreading
• @karol-bisztyga and @piaskowyk for helping me understand a few parts of Reanimated better
• @Szymon20000 for taking time to review and merge my Reanimated PRs
• JNI tips and fbjni to make Android JNI interop easier
• @iamyellow for being a huge help on the Android side
• Erik the Coder for the Icon
• You, for appreciating my work

Note: Technically this is not multithreading, but rather multiprocessing.