Threader is Easy to Use, Promise Based and uses Send Data Get Data structure.
Threader was made to make working with Actors easier and overall tie everything together.
Once Threader had dispatched the work and all the threads had finished, it will return all of the
data that the threads had returned.
Creating a Threader class is very simple. The first argument is always
how many threads are there initially and the last one is the ThreadWorker itself.
local Threader = require(game:GetService("ReplicatedStorage").Threader)
local myThreader = Threader.new(5, PATH.TO.WORKER.MODULE)
Creating a ThreadWorker
A ThreadWorker is a ModuleScript that is used to process the data in all of the threads
once Threader:Dispatch() was called.
local myThreadWorker = Threader.ThreadWorker.new()
function myThreadWorker:OnDispatch(data)
return data
end
function myThreadWorker:OnCancel()
print("Cancelled!")
end
return myThreadWorker
Get the Data Back
Getting the data back from all of the threads is very simple! Since Threader is Promise
based after calling Threader:Dispatch() a Promise will be returned that will resolve
once all of the threads had completed or gets rejected if any error occurs!
Main script
local myThreader = Threader.new(5, script.MyThreadWorkerModule)
myThreader:Dispatch(table.create(1000, 1)):andThen(function(results)
print(results)
end)
ThreadWorker
local MyThreadWorker = Threader.ThreadWorker.new()
function MyThreadWorker:OnDispatch(data)
local sum = 0
for _, num in data do
sum += num
end
return sum
end
return MyThreadWorker
This is a pretty awesome resource! I’ve been needing to utilize actors more for some stuff I want to do in The Wild West , and this saves me a bit of time
Thank you very much! Please let me know later down the line if you would like to see some changes made to Threader that I might have missed when developing it!
Thank you! When I wanted to play around with actors as well I noticed that most of the libraries that were made already required some kinds of preparations to use such as pre-making the actors. This was the main reason that Threader was created to focus on the main part: programming. The rest is taken care by Threader. No need to create actors or set-up boilerplate code so that you can retrieve all your precious data! I hope you will find a good use for it. Happy coding : )
Is this currently working?
Been trying it, used your exact repo, nothing is working.
Have not really tried actors or parallel lua, so is there something I need to enable for this to work?
That’s interesting. I’m guessing everything was synced into the right place with rojo. By that I mean Threader is in ReplicatedStorage, the test/Server is in ServerScriptService and test/Client is in PlayerScripts.
Could you perhaps take a picture of your explorer and all the files that belong to Threader are expanded? I have a guess but I’m unsure with the lack of information I have about this problem.
If Threader’s .project.json is used then it should work fine. However if the project was cloned and not Threader’s .project.json is used then there are more steps needed to make it work. This is how it should look like:
This .project.json assumes that Threader was places under a folder called vendors!
I’m sorry if you find the installation tedious. I’m currently working on getting the library up and running on wally and getting it on the roblox marketplace. For tomorrow/today these installation methods will be available.
For the problem I tried recreating it multiple times directly downloading the source and then using git to clone evaera’s Promise library into vendors/Promise. I even tried the installation method listen on Threader’s website to double check. In both cases I ran into no problems.
I can only think that rojo might be the problem here since I used version 7.4.0-rc3. But again I highly doubt it since it seems that all the scripts did get their RunContext property set correctly.
I’m very sorry that I could not figure out the problem, however here’s the compiled version that includes everything: Threader Dev.rbxl (37.6 KB).
You’re good bro! It’s all the process of releasing tools for the public! This file you provided seems to work, how weird that my exact same setup is not working. Starting to think perhaps there’s some sort of property I need to enable for it to function properly (my layout is the exact same as the file you provided).
Or perhaps an outdated Promise I’ve imported? Nonetheless, cool contribution, going to use this for some dope projects!
Thank you very much for your kind words! I really appreciate the feedback. I would be very interested as of what caused your issue! Possibly I could even point it out on the documentation.
Done some quick testing. Something I’ve completely missed was when I cloned the repo > started up a rojo server > connected to it in Studio. The ThreadHandlerServer and ThreadHandlerClient had their RunContext properties set to Legacy. I do believe this is the issue, is this because I have an outdated version of Rojo that do not support the RunContext in the meta.json files, or is it just not supported at all?
Connected from Rojo using your GitHub repo:
Properties:
I’m pretty sure Rojo started supporting the RunContext property from versions 7.3.0 and beyond. The main reason why RunContext was used instead of making a local script and a script is to move the threads out of the way and protect server sided modules from the clients.
When developing it I used to just parent everything under the module but realized this would not be a good approach since now everyone would have access to the server sided modules placed under ReplicatedStorage. As far as I know exploiters can decompile and view the source code of the modules even when not required.
Thank you for responding back and I will be sure to highlight it on the documentation that an up-to-date version of rojo is required!
Added link to video that Terrain Generation was based on
Added notice of required Promise version
Added notice of requireed Rojo version
Changed present installation methods to support Wally structure
Changed explanation of each variable in Terrain Generation
Changed Send Data Get Data pro
Closing thoughts
These will probably be the last changes made to Threader unless some bugs need to be fixed or a feature gets requested that is useful.
Threader is already at a very good stage where it can be used in production without any known bugs. Most of the inner workings of Threader were optimized to my best abilities and the most crucial methods were implemented.
I think adding more methods would be unreasonable. However if there would be feel free to open an issue and I will look into it.
Updated wally package and Github release! Please update to the newer release as it fixes ThreadHandler’s not connecting to the topics in time resulting in them missing the :Dispatch request by Threader!
