BadSignal - proper signal thread wrapping

BadSignal

Github: here


Basic info

This module focuses on proper coroutine function wrapping rather than speed. As such, it is quite slow compared to other similar signal modules. Hence the name Bad.

But the name Bad would only apply if you would improperly connect your signals or use them. This module can surpass the speeds of other modules in some cases.


Example usage

local BadSignal = require("./BadSignal")

local signal - BadSignal:new(1) -- allocate 1 connection
signal:Push(false,print) -- specify if we yield and connect the function itself
signal:Fire(12,"hello","world") -- fire with any amount of args

As you read, you most likely noticed that there are some oddities, like added false to the connection or the number argument in the constructor. That’s where the power of this module comes in. You can read more about it on github, but those arguments are what can make this module a lot faster than any other solutions out here.

Other signal modules combine thread and direct calling by having a single thread, and in case it yields, they simply create a new one. This one also combines both thread and direct calling but in a much more direct way, allowing for a much faster execution.


Summary

I created this module due to the lack of proper thread safety signals out there. So it is very unconventional in both terms of formatting, OOP model, and execution method. Also, this module requires specific usage in order to be efficient. So it will not fit all of your needs.

3 Likes

I don’t really see the use case for this.
Could you give an example?

Just like any other signal module. It is simply there to make signaling without the usage of RBXScriptSignal. Although it can be optimized for your needs. It works especially great if you do not call any yield functions.

Isn’t that a bit too hypocritical to say? You are also the developer of Signal+ and now judging a potentially better module than yours.

How is it hypocritical? I gave feedback on a product in which category I know a bit about — and then you say it’s hypocritical?

Oh so it’s faster, but it requires you to manually allocate connections etc?

It rather requires you to manually say if your function calls any of the yielding functions. Basically, it is a glorified function collector and executor with an added ability to wrap some of them into threads. For the actual allocation part, you have the ability to pre-allocate, but just as any Lua table, it will automatically expand its size without any issues. Although preallocating might save you a bit of time on connecting events.

2 Likes