Will Function Still Execute Even After disconnect()?

Hi! This is kind of a basic question but I just want to make sure I have it understood: Let’s say I have a function foo connected to some BindableEvent bar and bar has just been fired (i.e. bar:Fire()). While foo is executed and running asynchronously, bar’s association with foo is disconnected (i.e. foo:Disconnect()). Are asynchronous executions of foo canceled or prevented from executing even though bar:Fire() was called before the disconnection or are they guaranteed to execute no matter what (not sure if my question makes sense and if not then I apologize)? Thanks in advance! : )


Because disconnect will stop the function from occuring

I think it might be dependent on your selected signal behavior in workspace, In my testing, deferred doesn’t stop the function from running, it still runs despite being disconnected.


nvm, i tested on all behaviors (deferred, ancestrydeferred, immediate, default) and got the same result. so it isnt dependent on the signal behavior

tl;dr I believe :Disconnect just removes the function from the task scheduler’s connections, and does not suspend all ongoing connections when disconnected

1 Like

U have task.wait bruhof course it will not disconnect

Task.wait() means infinite waitng

please test it out yourself because it clearly printed “disconnected”, which mean it did not infinitely yield. task.wait() without any arguments just waits for a single heartbeat frame.

(even without task.wait() it still gets the same result)

I did test and it did disconnect

But there is a slight differnece from mine to yours

Local connection;connection = script.Parent.Touched:Connect(function()) end

This is my code

I disconnect this and it does disconnect

thats what im trying to say?? task.wait() without arguments does not mean it will infinitely yield

theres no disconnecting in your code?

Wait but task.wait() is unreliable if player have to wait a certain amount of time

U should put task.wait(3)

Its supposed to be a quick demo test, not for actual practical use. I don’t know what the OP wants to do with this and how did you come up with the player having to wait a certain amount of time?

(can we please stop going off-topic? im just trying to help the OP)

Ok its fine just make this a sa soultion cause i think it is solved

1 Like

Short answer: It will run the active thread if there’s one

So connections work like this:
Fires → Checks for connections → Spawns all connections in separate virtual threads

So that means that if you do Event:Fire() and without yielding Event:Disconnect() the thread that was spawned by the first Event:Fire() call will continue running

1 Like

Interesting, I had slight speculation that this may be the behavior! Also, a little off-topic but I noticed that you used a Once() for the connection (guessing this may be a “new” feature), and upon reading about it, it seems like it disconnects automatically (hence “Once” lol), is it recommended to use these over manual disconnection? Many thanks!

1 Like

Once is basically syntactic sugar for

local Connection
Connection = SomeEvent:Connect(function()
    -- code

This is a pretty common pattern for events you want to listen for just once so they moved the implementation into its own function Once. Now you don’t need to worry about the local variable or the explicit disconnection since it handles that for you, and the overall code will look cleaner.

If you know you want to listen for an event just once, I’d say it’s recommended to just use Once instead of what I showed above.

1 Like

Sounds good, I’ll definitely give this a try! : )