[v.65] SimpleSignal | Very Simple & Silly Fast Script Signal

Resources Community Resources
,
#21

I have found an issue. Memory leaks. :scream:

So in Once and Wait connections, you’re calling :Disconnect(), which closes the thread.
If you didn’t catch it already, you’re trying to close the thread from the thread, which isn’t possible.
It actually errors, but you don’t get the output since you use coroutine.resume instead of task.spawn.

This is actually a flaw in the thread storage system, which is problematic because i just released an update including it in my signal module. :frowning:

I’ll see if you have a solution for this. I haven’t been able to find one. I might have to unrelease the update for Signal+.

2 Likes
#22

Ahh that makes sense, I can think of a solution right now. However… I gotta sleep :frowning: I’ll see you tomorrow

1 Like
#23

Package Version 53:

  • Fixed memory leak (thread not being closed) when calling RBXScriptConnection:Disconnect() (it also works properly now)
#24

The issue was not :Disconnect(). It was Once and Wait.

#25

I know, and Once and Wait uses :Disconnect(), so the new fix means they get cleaned up properly now

1 Like
#26

You can’t just do a check. Sure, you’re avoiding an error, but the coroutine is still not being closed…

#27

It is being closed; the coroutine returning means it is automatically turned into a dead state (see threadWorker), the closing is just when the coroutine isn’t doing anything aka is waiting for a signal, so you can just close it immediately

#28

I see. I don’t think the method is worth it anymore. I won’t be using it, because you’re loosing a lot of speed many other places, and it wasn’t even near the 10x fire improvement which I first expected.

task.spawn is the true speed killer. But it’s really unavoidable. :frowning:

#29

Yeah there is quite a bit of speed loss with Connect and a little with Disconnect, however not enough to notice since most of the time you’re only doing Connect once; imo fire times is much more important

Idk man I’m still getting around 10-12x fire improvements for my own benchmarks

#30

Yes, because you’re using coroutine.resume. Try switching to task.spawn.

#31

Ahh yeah, task.spawn is the real speed killer indeed. Honestly I think the small tradeoff in having to do custom error handling is worth it for the speed improvements, if you don’t wanna use this method that’s fine; everything has its cons and benefits afterall :slight_smile: , SignalPlus is still pretty good compared to other signal modules which use the method of thread recycling

(also i ran out of heart again aghahgahhghhgahgah)

#32

You can’t do proper coroutine error handling. SimpleSignal now has a major issue; if a coroutine yields, it breaks, because it waits for it to finish (because it gets the success which only returns when the coroutine is finished).

#33

Errm actually, for some reason, the error is done… after it has looped thru all the connections? Idk it’s really weird, I myself don’t really know how it works

I assume it’s something in the luau VM which delays stuff which uses expressions related to the return values for coroutine.resume until it ends and/or errors, donno

#34

No try while true do task.wait(1) end in a connection. It won’t work if it’s fired before the other connections.

#35

Idk what you’re talking about man

image
image1911×309 27.6 KB

#36

Nevermind, I see. That’s extremely weird.

#37

I don’t use a linked list; I insert in an array appending to the end

#38

Yep I have absolutely no idea how it works. If I wait a second the fire code is far past the success/error check, yet if I then error there… it works magically.

#39

Wait… Your error handling does absolutely nothing.
It’s simply because you are using task.spawn when connecting. I guess the error handling still works when you thereafter resume with coroutine.resume.

#40

Ooh, even better news then

Actually I just tested it out and Roblox error handling only overrides mine when you yield, when you dont mine still works :)))