Could GetPivot be added as a safe method, or is this impossible?
3 Likes
Is this behavior expected? If I fire a BindableEvent from an Actor, and listen to it from the main thread, it appears that the code running in the main thread is in āparallelā mode still.
-- Main thread:
bindable.Event:Connect(function()
workspace.Baseplate:Destroy() -- Will throw error: "Function Instance.Destroy is not safe to call in parallel"
end)
-- From actor:
task.desynchronize()
bindable:Fire()
Seems like you got task.desynchronize and task.synchronize mixed up.
task.desynchronize() is used to enter parallel mode.
task.synchronize() exits parallel mode.
Yup I understand. My question is related to the fact that it is still desynchronized within the event handler in the main thread. I am trying to understand if that is an intended behavior, since it feels like it could cause some headaches.
1 Like
Ah alright, I think this is intended behaviour but I donāt really know. 
1 Like
Really loving this feature, itās allowed me to do real-time map generation that I could have only dreamed of previously. Currently able to render a map the size of South Carolina!
Any update as to what month actors might get BasePart property access? Iāve got it all organized into chunks so that second actors can make updates to parts under them Iāll be able to get even better performance, hopefully giving me the bandwidth to provide more close-up details.
Thanks again for all your hard work!
1 Like
Nope! The fix for this should be out in the next release.
7 Likes
Iāve been having this issue recently and itās been really annoying, I found a work around for it though.
Call task.synchronize right before running anything else in the event.
-- Main thread:
bindable.Event:Connect(function()
task.synchronize() -- Workaround for this
workspace.Baseplate:Destroy() -- Will throw error: "Function Instance.Destroy is not safe to call in parallel"
end)
-- From actor:
task.desynchronize()
bindable:Fire()
According to fflag changes, this feature went live today.
Iām not sure if this is a problem of not all changes rolling out to clients yet, but trying to play my testing game with the client causes an immediate crash. Just want to report this here to be safe before it goes live.
Game link: Water Testing - Roblox
5 Likes
Has anyone else started noticing mysterious errors like this popping up from scripts that are not under Actors, are not desynchronizing, and are not and have never used parallel API whatsoever? Probably related to the flag getting flipped today.
These errors are one-offs and seem rare, happening totally at random. I only found these two today.
This code is initialized from a server script that requires a hierarchy of server modules. This function is run on PlayerAdded, and the code thatās erroring runs after some HTTP calls and some datastore calls. The datastore module is third party (DataSync by Mullets) so I donāt know exactly what itās doing.
SetupServer requires SetupPlayerJoin which connects to PlayerAdded which fires onPlayerAdded, etc.
This code has not been updated for a while. There is no parallel Lua whatsoever.
8 Likes
This has been happening to me too. Especially a month or two in Studio. (Parallel Beta)
1 Like
is there any ETA when this will be released to fully?
4 Likes
Iāve had this issue for like 2 or more months at this point.
One thing, I had an issue not even using RBXScriptSignals, just using task.spawn, the one thing in common here is that we were doing HTTP requests, in this case I was doing DataStore requests, might be a coincidence or not, but itās good to note for anyone fixing this, so 
A fix for these random errors has just been released in Studio 499
5 Likes
Sorry for bumping this up (I donāt think it bumps but anyways), is there are an estimated day for when this feature will be totally released (I donāt even know if is released)? I need to use it for my game. By the way when I was testing with it, I wonder why if you execute some expensive code in performance freezes the main lua thread?! I ran a while loop without wait in parallel and it froze all. I also had another loop before I executed the parallel code with a wait and it was printing all it could.
task.wait(10)
local Value = 0
task.spawn(function()
while true do
task.wait()
Value += 1
print(Value)
end
end)
task.wait(1)
task.spawn(function()
task.desynchronize()
while true do
end
end)
I expected the coroutine on the top to continue running on the back even if the thread froze all but this didnāt happened. It printed around 57 and stopped. Since is waiting for the other loop to finish. Anyways once it timed out the loop continued printing and it started from 58. I thought it would be in like 300 already but nope. Is this really parallel and if so, is this the behavior?
Parallel Lua doesnāt run in parallel with the entire engine, but only with other Lua threads. If one of your threads takes too long to finish executing itāll probably drag out all the other ones that already finished.
2 Likes
Would you mind sharing the source code/place for this? I would love to see a proper example of parallel luau being used as Iām sure many of us are curious.
1 Like
I think task.wait() caused lag for my game please help
That shouldnāt happen just because of task.wait(), what is the script your putting it into?