I searched beforehand. If I missed the thread discussing this, please let me know!
I’ve generally been conditioned to believe that connecting to a signal several times over is bad. I don’t know where I picked that up from but I did and that’s causing me bouts of counterproductivity where I try forcing my code to follow some elegant or overcomplicated pattern that it ends up becoming inelegant.
With that said, simple question. When you connect a function to a signal (for example, you have several CharacterAdded functions to handle different parts of code when a character spawns), do all the connected functions run relatively in parallel when the signal fires? Is connecting to a signal multiple times bad or should I aim to do that over trying to force all my codework into 1 or so connections?
I’d also like to know what goes behind functions connected to a signal when they’re called or connected, if anyone’s willing to impart that knowledge. I’m not fully familiar with it myself so I’d like to be brought up to speed about that.
To restate, my questions:
Do functions connected to a signal run at relatively the same time when the signal fires? Maybe in tandem or akin to spawn/coroutines?
Is connecting multiple functions to a signal bad?
Any extra information that can help me understand the script signal workflow.
Firstly, Lua is single-threaded. Any event listeners which you have connected will be resumed in sequence and not in parallel.
Sort-of, anyway.
When a function listening to an event is called, a new coroutine is created for it to run it. All statements in a function will run until they yield, at which point the next function is resumed. In Lua, resuming event listeners could look like the following:
local listeners = {}
local function fire(...)
for i = 1, #listeners do
local routine = coroutine.create(listeners[i])
coroutine.resume(routine, ...)
end
end
To answer your question about whether or not it’s bad to connect multiple functions to a signal; short-answer, no. Long answer, it depends on what you’re doing. If each of those functions is connected to an event which is fired every frame, and they each perform a raycast… that’s probably not the best idea. That said, this only matters if your game is performing badly. If it’s running smoothly, don’t waste time worrying about it.
Yeah. I was wondering if they would run anything close to parallel. Naturally, with Lua, all chunks are executed sequentially as tasks within the scheduler. This answers it more or less though.
A question regarding the behaviour you specified about event calls: when you refer to the behaviour of a new coroutine being created to run a function, is this done internally when a signal fires for each of the connected functions for all types of RBXScriptSignals?
A second question, though it’s more specific to your example despite this kind of thing being circumstantially dependent: you mentioned a function that fires per frame and involves raycasts. I was under the impression that raycasting every frame should be inexpensive to run so long as the casts are short? I do believe the engine does this internally as well for some things such as Humanoids.
And a final question, but it’s more of a future prospect than anything. I do believe that something regarding multi-threaded Lua was discussed at RDC but it wasn’t a guarantee. If this is anything realistic and you have any information about it, would this change anything about event calls in the future?
This might not have been the best example. Raycasting a short-distance each frame is fine, if you’re performing hundreds of them though, and they aren’t short, don’t expect your game to be performant. I’d refer you to the follow-up. This only matters if your game is performing poorly.
Unfortunately, I do not know anything about this. It should be safe to assume that this behavior won’t change anytime in the near future, but of course keep an eye out for any updates in #public:public-updates-announcements which might be relevant.