Just for clarification, is the task.delay call not executing or is it the function provided in the call?
Did you try to change the task.delay number to Int Value? instead of 21.1 to 21
When you say the thread is getting garbage collection, do you mean it is going into the "dead"?
Spawned threads should resume through the task scheduler regardless on their parent thread’s state, so either something is yielding or killing the callback before it can spawn the thread.
If you believe GoodSignal is the culprit, then try replacing it with a naive implementation that doesn’t do thread reuse (stravant made this one).
1 Like
task.delay is executing but is remaining permanently suspended and yes I have checked the duration.
1 Like
Why would this be an issue? It worked perfectly fine before.
Yes this is the case. I will try using SimpleSignal to see if it rectifies any of the problems I am facing. The thread is being killed for whatever reason and it’s causing the task.delay to forever remain suspended and the same thing happens with task.wait and task.spawn doesn’t fix the issue either.
Cause roblox trolls
I don’t really think the delay time not being an integer would cause any issues.
1 Like
That’s very strange. I’m not sure of a condition where that would happen.
Per the docs:
the very same Heartbeat step in which enough time has passed, the function is guaranteed to be called/resumed
Based on the code in your function, the coroutine returned shouldn’t possibly be in the suspended state after the delay, since it doesn’t do any yielding.
[Edit: If Dice:NextNumber or .SetGameSetting yields this might be possible?]
This would lead me to believe this is a problem on Roblox’s end perhaps?
Out of curiosity, does using
task.spawn(function()
task.wait(delayTime)
-- Your code
end
Do anything different? Or does this seem to happen with all threads given to the engine’s scheduler?
We’ve already checked and .SetGameSetting does not yield. This issue only happens with callbacks given to GoodSignal via :Connect()
1 Like
Is there task.cancel() somewhere?
Nope, the thread gets reused by GoodSignal somewhere and prevents the task.delay from running.
Hmm, can you add
local Task = task.delay(…)
Maybe the script is deleting the task.delay() because of the :Connect() Signal, firing again as you said GoodSignal gets ReUsed
by turning it into local Task, it should fix that problem normally.
Since GoodSignal is already a task, as we look into the Module at line 151, 164
I’ve already tried making a strong reference to the task.delay but it still remains permanently suspended. Perhaps it may not be a GoodSignal issue but more rather a ROBLOX issue? The only reason I have a suspicion that it’s GoodSignal is that all of the incidents have been happening inside of connections made by GoodSignal.
I have one stupid idea that could work
task.spawn(function()
task.delay(3, function()
print("Running delayed task")
end
)end
)
This wouldn’t work because the thread will still be garbage collected.
Can I see what it looks like where you calling hte onGameSettingsChanged() function?
It’s at the bottom in the second screenshot.
I doubt it is an issue with the garbage collector.
Here’s an example of a single thread being garbage collected:
Here’s an example of GoodSignal’s implementation, even with a thousand threads:
This would not even matter since GoodSignal only ever reuses 1 free runner thread.
Threads are not true parallel. This means that running coroutine.running on a thread outside of said thread will never give you a status of running. Add a print to your task.delay thread to see if it’s even running. If it does, the problem likely lies with the function that has been passed.
This might be related:
I’ve also experienced weird task scheduling behavior, so it is entirely possible this really is a Roblox issue.