After months of iterating on the feature and with the help of the Roblox community, we are happy to announce that Parallel Luau has graduated to General Availability. This feature allows developers to break their experiences up into logical sets of actors, and was released first as a developer preview and then as a studio beta.
To get started with Parallel Luau, you can check out this article. In addition to this small tutorial, the API documentation now includes tags on every method and property.
Starting today, all methods that modify instances are marked unsafe, and no properties are marked safe to be written to in parallel. Over time we expect to slowly make more of our API methods thread-safe as we continue to improve the Roblox engine.
We are also exploring more APIs specifically targeted at parallel execution to make it easier to convert existing experiences to use actors as well as introduce new ways to communicate data between actors. Rest assured, this is just the first release. We will keep working on maximizing efficiency and ease of use of parallel script execution.
It has been amazing seeing all the things you have created during the beta period. We can’t wait to see these creations in their final form as live experiences.
Major Changes Since the Beta:
-
Scripts that call synchronize and desynchronize can change between states within the same frame. See details in the following section.
-
The debugger now works in script rooted under Actors, both in parallel and serial contexts.
-
require()is no longer allowed during the parallel phase. Require scripts you want to use first in a serial context.
- Access to some properties in the
RaycastParamsandRaycastResultobjects have been marked as unsafe. We hope to loosen this restriction in the future.
Multiple synchronize/desynchronize within the same frame
Some of the previous examples showed code to the effect of:
while true do
task.desynchronize()
dowork()
task.synchronize()
end
… to do some work every frame. This will now result in the dowork() function being called multiple times per frame as the state transitions between parallel and serial do not require the engine to advance to the next frame. The task.wait() function can be used instead of task.synchronize() to wait one frame.
The number of transitions per frame is still limited, so code using the older paradigm will not crash your game, but will likely be inefficient and not do what you want.
