Would a Rust wrapper for R be thread-safe?

[jdhoffa]

I would like to understand more about R's limitations in terms of thread-safety, to make sure that we are careful in our design implementation of this package such that we can guarantee it's safety.

To do so, I thought I would start a discussion on the topic.

R is not thread-safe

As I understand it, the primary reasons for R's lack of thread safety are:

Internal state

R’s internal state, including it's memory management and garbage collection, is not designed to be thread-safe. R’s memory allocation and deallocation are not atomic, which can lead to data corruption and unexpected behavior when multiple threads access shared data.

Non-atomic operations

Many R operations, such as assignments, vector updates, and function calls, are not atomic. This means that concurrent modifications to shared data can lead to race conditions, data inconsistencies, and incorrect results.

Global variables

R’s global variables, such as .Machine, .Random.seed, and options(), are not thread-safe. Accessing or modifying these variables concurrently can lead to unpredictable behavior and errors.

[jdhoffa]

My gut feeling is that, so long as we implement a design pattern where:

• R passes arguments/ data into Rust
• Rust spins up multiple threads, computes some things, spins down those threads and returns data
• Data is presented to and output by the R process

Then we can implement this safely.

But curious for other's thoughts here