With the recent release of the Parallel Luau and SharedTable APIs, I’ve been investigating some of the best practices on how to use these APIs as intended. However, I ran into a minor concern about getting SharedTables across multiple actors.
Currently, I am having my actors create any necessary SharedTables at the start of my scripts. Any other scripts that require a SharedTable from a given actor then calls GetSharedTable to obtain it. Depending on when GetSharedTable is called, it can either return the defined table or an empty table if the table hasn’t been defined yet or doesn’t exist.
However, sometimes I run into scenarios where I attempt to get a SharedTable from an actor that hasn’t been defined yet. In these cases, I find myself writing spin-lock-like code that waits for a shared table to exist. Although this works, it feels sketchy due to its design with the possibility of an infinite yield if something goes wrong.
Here’s an example of what I mean:
At the start of a certain actor I have, I create and register a SharedTable as early on in my script as I can. Unfortunately, sometimes when I try to retrieve this table from another actor, the SharedTable doesn’t exist yet. I end up having to write code like this to wait for the SharedTable:
Using .size() to determine of the table exists likely isn’t the best design choice; my main concern is using this while loop structure to wait for the table to exist. In addition, I wouldn’t like to write overhead that waits until a SharedTable is fully populated with the key-values I expect. It would be nice if there was a “:WaitForSharedTable” function that yields my code until it retrieves a populated SharedTable, similar to the WaitForChild function.
Hi @Kyles45678,
Thanks for your feedback. I have a few ideas about ways to accomplish what you are after. Although they may not be a perfect fit depending on how your systems are organized. So please just consider these as potential options that may, or may not, be a good solution for your situation.
One option is to “push” vs “pull” the shared table. By that I mean the code that creates the table could send a message (e.g. using Actor::SendMessage) to other actors that contains the shared table they need to access. This is often a very convenient solution, but it does mean that the sender “knows” what actors to send the table to, and this information may not always be available.
Another option would be to use a BindableFunction to query the shared table. Or similarly use BindableEvent to signal that the table is available. Both of these options use existing Roblox API’s and would avoid looping until the table is available.
Using a “Promise” API may also be a good solution. Although I haven’t investigated this option to know if existing Promise libraries work well with Actors/Parallel Luau.
Finally, I will say that having an API to wait for the table isn’t a bad idea. Our main concern is that we prefer to provide general mechanisms/API’s when possible. So having an API that specifically waits for a table to be made available is probably not our first choice for how to solve this issue. Having a general system that allows waiting on various types of objects would likely be our preference. Although please let me know if the solutions I mentioned above are helpful or not.
