GoodSignal::Connect thread gets garbage collected after yielding

Help and Feedback Scripting Support
#1

This issue has been plaguing my game as of recent and we’ve tried different signal implementations like LemonSignal we initially thought that it was a ROBLOX update as things were doing just fine before.

To explain my issue whenever I run :Connect() on a GoodSignal and yield for x amount of seconds the thread gets garbage collected which results in unintended behavior with doors, elevators, etc.

Our game has aged quite a bit as it was made in 2022 by someone who was not as experienced at programming. I’ve been working at this game as of January 2024 as a Lead Programmer with my colleague remarkablebeauty.

Here’s a snippet of our server code where the issue is present

image
image2051×1527 321 KB

image
image1088×49 12.3 KB

2 Likes
#2

Do you have a link to the GoodSignal module you’re using? Is it this one?

#3

Yeah I’m using the current GoodSignal implementation.

#4

Are you able to create a minimal repro? I’m trying to reproduce what you’re seeing with the following code:

local OnEvent = GoodSignal.new()
local Connection = OnEvent:Connect(function()  
	print("Running callback")
	
	task.delay(22, function()
		print("Running delayed task")
	end)
	
	print("Finishing callback")
end)

OnEvent:Fire()

It works as expected though.

Edit: Are you thinking it’s a bug with GoodSignal or with your game code?

#5

I’m feeling like it’s an oversight on our part but also maybe a bug of GoodSignal.

The code you have provided should reproduce the same issue but I have a feeling this issue is related to the reuse of threads.

#6

Out of curiosity, what do you have your SignalBehavior set to in the workspace?

Nevermind, I doubt that changes anything

1 Like
#7

It is set to Enum.SignalBehavior.Deferred as recommended by ROBLOX themselves.

#8

Yea, I’m not sure why that’s happening. I’m not able to repro the bug on my end.

My only suggestion would be to try and refactor the code to avoid using as many task.delay and task.spawn calls. Sorry I can’t be of more help :confused:

#9

No worries! I will also mention that we have tried to replace it with task.wait to no avail, the thread still gets garbage collected.

#10

I will also mention that we are actively trying other signal implementations to see if they fix the problem.

#11

Okay so I assigned the task.delay thread to a variable inside the script and when it doesn’t run I check the variable to see what happened using coroutine.status and it returns suspended even though it’s way past it’s delay time. Is there any fix for this?

1 Like
#12

I’m just gonna go ahead and bump this.

#13

Just for clarification, is the task.delay call not executing or is it the function provided in the call?

#14

Did you try to change the task.delay number to Int Value? instead of 21.1 to 21

#15

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
#16

task.delay is executing but is remaining permanently suspended and yes I have checked the duration.

1 Like
#17

Why would this be an issue? It worked perfectly fine before.

#18

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.

#19

Cause roblox trolls

#20

I don’t really think the delay time not being an integer would cause any issues.

1 Like