Morning.
Yes, what @Megalomaniak said.
If you use multithreading, be sure that operations are always in a well defined order and don't break each other's invariants. Like if you modify a scene in a thread make sure that other threads don't modify that scene as well. Even read-only access can go wrong if an operation has not completed yet to a consistent state. This is true for any data modifying operation.
That means for a programmer to synchronize access to data via mutexes. To signal between threads, for example if they can continue or to wait for an operation to conclude, you use semaphores.
That said, signals per se aren't thread safe, because they send notifications around to do things on occasions. In a multithreaded environment you'll have to synchronize these things. And there can be a lot of signals around. It is easier if all of them only perform read-operations on data, the scene tree, whatever, but if they start to modify things another thread is just working on then the outcome can be unexpected.
So the answer is yes, but depends on what's going on.
Edit: I wouldn't start a thread for a signal that fires frequently. Starting a thread on OS level is a costly operation, but idk if Godot threads are taken from a pool the engine has prepared, or really open an own thread like a low level language would. There's the buzz-word "thread pool", but idk if your case merits such efforts.
