Provide a convenient way to await thread finish.

[Daylily-Zeleen]

Implement #5918 and instead of #5893

[Daylily-Zeleen]

Well......how can I handle this error, I have not develope experience of mono module.

[raulsntos]

I think the await_to_finish method you add in this PR is the first one in Godot's API that returns a Signal, the .NET bindings generator seems unable to handle this situation since we never had this case in the API before and generates invalid C#.

Also, is this new API really needed? Can't you just await the signal?

var thread := Thread.run(do_something_heavy.bind(count))
var result = await thread.finished

[Daylily-Zeleen]

I think the await_to_finish method you add in this PR is the first one in Godot's API that returns a Signal, the .NET bindings generator seems unable to handle this situation since we never had this case in the API before and generates invalid C#.

Also, is this new API really needed? Can't you just await the signal?

var thread := Thread.run(do_something_heavy.bind(count))
var result = await thread.finished

In order to not hurt the origin feature, a way to start async process is needed.

Of course, we can avoid to return a signal to deal this problem.
For example, use func start_await() -> Thread instead of func await_to_finish() -> Signal, and use it like this

var result := await Thread.run(do_something_heavy.bind(count)).start_await().finished

But Signal is type of Godot Variant, for completeness of functionality, we should provide the ability of handle Signal for C#( I don't know the detail of C# in Godot). Even if we limit ourselves avoid this situation, we can't restrict developers to return a Signal.

[neikeq]

We do have support for Signal in the C# bindings generator, but this is the first time it's used and there seems to be an error. That can be easily fixed. It would take a bit more work to turn the C# type into an awaitable.

Regarding this new API, since this is the first time it's done this way, we need to decide whether it's the right way.

It seems the returned signal acts as a Future. I'm not a fan of it, mainly because Signal currently lacks typing support (Signal<ParamType>).

Additionally, it could be great to have a more specific API for this (futures and awaitables), ideally one that would work in C++ as well with co_await. This could always be introduced in the future, though, so it doesn't worry me as much.

[neikeq]

This fixes the C# bindings:

godot/modules/mono/editor/bindings_generator.cpp

Line 3654 in 0580790

itype.c_out = "%5return " C_METHOD_MANAGED_FROM_SIGNAL "(&%1);\n";

-	itype.c_out = "%5return " C_METHOD_MANAGED_FROM_SIGNAL "(&%1);\n"; 
+	itype.c_out = "%5return " C_METHOD_MANAGED_FROM_SIGNAL "(in %1);\n"; 

The C# type needs improvement (rename it from SignalInfo to Signal and make it awaitable), but it's already usable as is.

[Daylily-Zeleen]

Replaced by #70299.