Would like to add that it seems like FastSignal’s implementation seems to be just like Roblox’s :Once and so expect behaviour to be the same, if you think otherwise please bring it up over here (or well on GitHub, I’ll notice it faster there.)
What’s your reasoning for not re-using the same coroutine?
As far as I know the only “benefit” to doing so is all spawned threads being halted immediately / connections being disconnected when a script is removed if you use a new coroutine every time as with a simple task.spawn. In my experience almost everyone who wants to use a signal class wants to do it from a centralized system of modules where there are not script objects being created and destroyed anyways so that’s why I prefer the additional performance of reusing the coroutine.
Is that just in the name of matching the RBXScriptSignal behavior more closely or do you think that behavior is actually more desirable in practice?
I’m not sure why you thought I didn’t, but I do thread recycling on Immediate mode, not on Deferred because it doesn’t seem to be possible / doesn’t make sense. It also doesn’t happen in RBXScriptSignals on Deferred, but it does on Immediate.
The only thing that is different I believe from GoodSignal is how it recycles threads, I noticed the argument leak issue when first creating a coroutine before it was mencioned to you and I believe I updated my code to deal with that before, I’m not sure how you do it on GoodSignal since I haven’t really look at it for a while, but FastSignal should have some more cost when first firing and creating a thread to reuse than GoodSignal (at least when that was not patched) but should run the same way if no extra threads need to be created because a connection yielded for example.
This is one thing that I’ll never try to change for API parity, FastSignal tries to be as similar as it can, REASONABLY, to RBXScriptSignal behaviour, I wasn’t really aware of this, but things like disabling, destroying scripts is wrong enough to me to basically do anything for it to not matter to me, and I would never change my library for that much of a performance hit for the sake of something that is to me, deprecated ways of doing something.
Thread recycling has pretty big performance improvements even if its not just running the connection directly, which you can notice with a lot of connections running like you know, and while I usually am the person that would try to create completely unbiased libraries, disabling/enabling scripts is one of those things that even if a person isn’t using my library they will run into problems anyway, so I found that to honestly just not be important especially if it means losing the performance gains that Immediate has from thread recycling. (Which seems to be one of the biggest issues for people moving to Deferred when they relied on how Immediate performance logic worked)