Documentations for the new task class?

[Dehydrocapsaicin (DehyDev)]

I was introduced to these seemingly new stuff by a friend and it seems there is zero documentations to be found.

[gooey333 (StandardSatire)]

Parallel Lua Beta

After a flurry of bug fixes and stability improvements, we are happy to announce the Parallel Lua project has graduated from a developer preview release to a full fledged Studio Beta! Special thanks to all the developers who kicked the tires on the developer preview and provided feedback and demos. Important Note: For now, Parallel Lua features will only work within Roblox Studio! If you publish a place that has Parallel Lua API calls, things will be very broken. The Parallel Lua APIs can be…

[BenMactavsin]

Task library is not documented yet because it is added only recently and it’s functions are currently in beta.

task.synchronize() and task.desynchronize() are introduced with Paralled Lua Beta:

@EthicalRobot

The Basics of Parallelism

In order for your script to run in parallel with another script two things must be true:

• The scripts must be parented under different Actor instances
• The thread within a script must be desynchronized either via task.desynchronize() or Signal::ConnectParallel

@EthicalRobot

Currently you can’t modify any properties during the parallel phase. In the future releases we’re going to unlock the ability to modify the properties of the Actor’s instance hierarchy in a desynchronized (parallel) script. For now, to be able to modify any properties or state, you must switch back to the serial (“synchronized”) execution; you can do this by calling task.synchronize , which will suspend execution of the current coroutine and resume it at the next serial execution opportunity.

task.defer() and task.spawn() are introduced with Deferred Lua Event Handling Beta:

@zeuxcg

Should I switch to the new mode right now?

To give us a bit of time to carefully comb through the feedback, categorize it and make sure we have a plan for everything, we are changing the new mode to only be active in Studio. This more accurately reflects the status of this change, which is an exploration / beta.

Please still let us know when you find issues with this change. There is some leeway for us to change the behavior here; for example, people brought up FastSpawn as an example. I’m hoping that there’s no disagreement that FastSpawn is a hack and really shouldn’t exist - in fact, we have a set of new APIs like task.defer that should make it unnecessary, but unfortunately we didn’t correctly order this beta so you don’t have access to these - but if we need to keep it working, we can change rules around some events to be immediate, because specifically bindables are less problematic than other events as the engine will never trigger these directly.

@zeuxcg

@DataBrain

FastSpawn is meant to run a new coroutine immediately (which is already possible with coroutine.wrap and coroutine.create ), but in a separate thread that does not stop the current thread if there is an error, while maintaining full debug functionality

Yeah, thanks for this clarification. The initial version of my reply had task.spawn in it but we changed it to task.defer ; I thought that we already have a immediate spawn in our planned task. APIs but it appears that we don’t yet; we will address this as well.

task.delay() and task.wait() are added with the Release Notes for update 486 but their purpose are currently unclear right now.

Release Notes for 486

I see that task.wait() and task.delay() got added in this release, is there a time period later this year where they’ll be enabled to be used in production, as well as task.spawn()?

Edit: Turns out task.delay() and task.wait() pretty much does the exact same thing as delay() and wait() global functions respectively.

[WallsAreForClimbing (Climber)]

We enabled these recently but please refrain from using them in any published work until we make an official announcement about them. More to come soon.