func test():
my_signal.emit() # not a deferred connection
Given the above code, does the interpreter complete the entire process linked by the signal and then return to complete the function (pop the call stack I guess)?
I know that signals are not asynchronous but does it need to return to the function?
Adding a line after the signal will show that the signal code is processed before the next line but what if there is no next line?
I seem to recall in another language that event calls as the last line of the function did pop the call stack (iirc)
I would be surprised if that last stack push was optimized out, for normal function calls too. Very small optimization too, unless we’re talking about recursive tail-call optimizations, but again I’d be a little surprised from GDScript.
1 Like
To give this concern a practical example lets look at a state machine implementation.
I have State class with enter and exit functions and they connect a transition state signal to the state machine class.
All of the examples I have looked at fire up one of the process functions within the state and will emit the transition signal when one of the process loops comes upon the right conditions.
So it goes for State.enter(), State.physics_process(), StateMachine.transition(), State.exit(), NextState.enter().
This setup gives the enter function a chance to complete.
In my case I am not using the process functions. The first few states complete without any user interaction.
If I emit the transition signal at the end of the enter function then it will still be alive when the exit function fires and the next states enter function begins. This effectively makes the next state a sort of child of the first state.
Theoretically, this could lead to a big jumble.
The solution I am using is to connect using the connect deferred option. Seems to work.
In any case I was wondering what is necessary.
What?
This sounds like you are overcomplicating things, but TBH I can’t tell you without seeing your code and whatever node setup you’re using (if any)because I cannot visualize your architecture based on what you wrote.
I don’t think worrying about any of this is necessary.
I really do not understand why you think it matters how signals are processed if they’re at the end of the file, especially when you don’t seem to remember what language even did this. Sounds like you are borrowing trouble from the future, because you’re presenting hypotheticals on something very minute.
Slight correction.
“end of the function”, not “file”.
1 Like
Apologies. I realize that came across harsher than intended.
I had trouble parsing what you said. I’d be happy to give feedback on your state machine code if you’d like to share it. From what you describe I cannot tell why you think you’d run into an execution problem.
If you don’t want my feedback, no worries, and no offense taken. We are here to help each other when we can.
If they did tail-call optimize it, then the optimization would have to only be if there is no destructors called (you would essentially have to have no other local variables in the function). Otherwise it’s not an optimizations, instead a breaking change, which any good compiler is forbidden from making.
It’s a rare optimization to take advantage, again only really relevant to tail-call recursion for both performance and application. Ends up sounding like we’re talking about an XY problem
The emitting a signal immediately runs it’s connected functions and when complete returns to the calling function. Very similar to calling any other function from another function. So, in your real code do you have statement after the signal emit? If you want it to run a full-frame before the emit then using CONNECT_DEFERRED will do that for you.
I don’t think it’s necessary to connect deferred, you can position your code to transition states at the end of it’s function to prevent a mangled state.
1 Like
On the contrary. You are a good programmer and your feedback is welcome.
I am going to edit the nasty part of my response out.
Sorry.