Asynchronous Safeness is an abstract concept that explains the safeness of an async Context in the FrooxEngine, using ProtoFlux inside Resonite. This page goes over the weirdness and other strange things that happen when using async along with how one can make it safe.
Async tasks continues to run in the background, even when the host is away from a session/world.
Thread Safety
A task is NOT a thread inside the FrooxEngine (and is terminology reserved for Operating Systems), so starting an async task, it awaits/yields for the synchronous task if it is free first before running a part of a task on the async context.
Race Conditions
A race condition is the concept of two or more contexts running at the same time that refers to the same target/value/action and modifies or executes that change, causing an overwriting effect. Async contexts can cause race conditions due to not being synchronous, meaning that it is separate from the main task and has a change of overwriting something before or after the synchronous task.
Pseudo Asynchronous Connections
Delegating ProtoFlux context to another user (by use of Fire On Change, Fire On True, etc). Although, not an explicit async task, the same concepts still apply, such as Race Conditions and Thread Safety. This effectively queues a "task" for a user to run, and there could be an amount of wait-time before the listening context (Fire on change) can fire.
Locality
This effectively keeps async tasks "safe", as it is run on the client side, making it mutable (immutable is shared across all tasks). This prevents data from changing without the user being aware of it first.
Examples
TODO: Make an example that shows slot traversal in ProtoFlux, showing both the safe and unsafe way using Start Async Task.