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! : )
Answer:No
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
Connection:Disconnect()
end)
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! : )