You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OS/device including version:
Ubuntu 19.04, Windows 10
Issue description:
I want to emit a signal in a thread to notify that something new is available, so that it can be handled safely in the main thread. However, it seems like when I emit a signal in a thread, the function which is connected to it is not thread safe as well.
Since the errors are very hard to interpret (usually something like 10054 socket error), it's hard to know where exactly something unsafe is happening. I think the documentation needs to be extended with how signals and threads interact.
If this is really currently not the case, it would be very helpful for signal handling to always be thread safe, no matter where it came from. Until then, I see this mainly as a documentation issue (there is no mention of signals in the 'Thread safe APIs' page).
The text was updated successfully, but these errors were encountered:
Signals are just as safe as function calls, unless they are set to DEFERRED they will run as soon as emit_signal is called, if you are crashing when calling emit_signal in a thread you are doing something non thread safe in the handler, the signal call itself is safe (as long as you are not adding new connections during that time).
Aha! I thought emitted signals aren't handled immediately, but in a different processing stage. That's why I originally assumed emitting a signal in a thread is safe, regardless of the handlers.
Will the handling functions be run in a thread safe way when using DEFERRED?
DEFFERED is run at the end of a frame by the main thread.
So technically it isn't thread safe if some other thread accesses the same thing (aka if you write some value in a thread at the same time as the main thread is accessing it in your signal handler), but if you are accessing some functionality limited to the main thread then yes it is safe.
Right, makes sense! Honestly, things like this should really be in the thread safety docs - debugging them can be really frustrating, especially with some basic information like this not being well available.
Godot version:
3.1.1
OS/device including version:
Ubuntu 19.04, Windows 10
Issue description:
I want to emit a signal in a thread to notify that something new is available, so that it can be handled safely in the main thread. However, it seems like when I emit a signal in a thread, the function which is connected to it is not thread safe as well.
Since the errors are very hard to interpret (usually something like 10054 socket error), it's hard to know where exactly something unsafe is happening. I think the documentation needs to be extended with how signals and threads interact.
If this is really currently not the case, it would be very helpful for signal handling to always be thread safe, no matter where it came from. Until then, I see this mainly as a documentation issue (there is no mention of signals in the 'Thread safe APIs' page).
The text was updated successfully, but these errors were encountered: