The docs for all the SDKs note that the worker connection object is not thread-safe, and the Steps for integrating a game engine page specifically notes:
… you need to be aware of that the SpatialOS SDKs do not offer any guarantees of thread safety - so you’ll need to account for that. This may cause the
Connectionto block your main thread. If you want multiple threads connecting to SpatialOS, you’ll need to coordinate it yourself, and take appropriate safety measures. For example, when you process events, you’ll need to be aware of your threading model, and make sure you’re not calling from the wrong thread.
I’m working on integrating SpatialOS into a game engine, and I’m looking for more information about how to correctly address thread safety for the worker connection object. Note that I’m specifically using the C API via the Rust programming language, but these questions should apply to all the SDKs.
In what ways is the connection object not thread-safe currently? There are differing degrees of thread-safety, for example:
- Is it safe to access the connection object from different threads, so long as only one thread accesses it at a time? Or does the connection object need to be “pinned” to the thread that created it?
- Are there any methods that only read from internal state data (which is never modified by other methods)? If so, these methods should be thread-safe. For example,
GetWorkerAttributes()notes that “Worker attributes are static and will not change over the lifetime of the connection”, so is there any reason why this method couldn’t be called by two threads at the same time?
- Does the connection object only ever modify its own internal data? Or does it ever read/modify global or static variables? If it only ever modifies its own internal data, then it can probably be made thread-safe by wrapping it in a mutex.
Any information you can provide about how the worker connection object works would be super helpful in ensuring that I’m using the API correctly