What is gd.Lifetime?

[ShirenY]

This repository appears to be very clean and promising. Upon examining the examples, I noticed that every Godot function, whether inherited or called, requires a Context as a parameter. While this isn’t a deal-breaker, it does seem redundant.

I looked into the internal code and found a comment explaining the necessity of providing a unique Godot context for each call. However, I’m wondering why this isn’t the case with other language extensions like C++ and Rust. Is this a safety enhancement implemented on top of Godot, or is there some performance consideration involved?

[Splizard]

why this isn’t the case with other language extensions like C++ and Rust.

This isn't the case for C++ because memory needs to be managed by the developer, this isn't the case for Rust, because the language has memory ownership semantics that provide memory safety. This isn't the case for the official Godot C# bindings, because in C#, Godot memory can be freed by the C# garbage collector, as presumably, C# has reasonable mechanisms to do this when interfacing with C.

Go doesn't have any language-supported (efficient and reliable) way to manage foreign memory (ie. Godot objects and values) via the garbage collector. It has finalizers, but these are not really meant to be used for lots of small-short lived references.

gd.Lifetime (inspired by context.Context) has been designed to address this. It serves as a representation of a lifetime, which Godot values are associated with, as well as a handle that can be used to access Godot globals (grow.graphics/gd does not use global state). They can either belong to a function, or an instance of a gd.Class created by Godot and will be freed when the function returns, or in the second case when the class instance is destroyed.

Is this a safety enhancement implemented on top of Godot, or is there some performance consideration involved?

It is primarily used to ensure memory safety, it shouldn't be possible to double free, use-after-free or to leak memory within a function when using the gd.Lifetime values passed to godot-called functions (as long as Godot doesn't free the value unexpectedly). The implementation of gd.Lifetime minimises allocations, when the total number of Godot references are stable, it shouldn't allocate Go memory at all. Reducing Go allocations is certainly a significant performance consideration and gd.Context helps to ensure that grow.graphics/gd doesn't force you to allocate Go memory when interfacing with Godot.

This repository appears to be very clean and promising.

Thanks for the feedback, the primary goals of this project are safety and performance, this does mean some aspects of working with Go+Godot will be a bit awkward and low-level. If you are looking to work with Go + Godot using more idiomatic types, string instead of gd.String you may want to try the Godot 4 branch of https://github.com/godot-go/godot-go, although I'm not sure they can offer the same level of memory safety, nor be able to keep to low-levels of memory allocations (and copy overhead).

[ShirenY]

Thank you so much for the clarification. You’ve chosen a very interesting approach to memory management.
I think I have a rough understanding, but as I’m neither a Golang expert nor a Godot expert, I believe I need a bit more education to fully evaluate this method.
I value both quality of life and performance XD, trying to find a balanced language to control this engine. I will definitely give this library a try.

[Splizard]

Hi @ShirenY, I've been thinking more about this and it may be possible to remove the requirement for gd.Context to be the first parameter for each exported class method. Instead, the class itself can become the container for lifetimes and the Godot GlobalScope. I would be curious to hear your thoughts on this (you would still need to pass a context-like parameter to any Godot function that returns pointerlike values).

[ShirenY]

I find it hard for me to evaluate this decision, primarily because I’m not entirely clear on the intended usage of the current context. For instance, in the issue, I created a global pointer to a newly instantiated object. I’m uncertain if this is a safe practice, though I suspect it might not be.

If it isn’t, how would I go about creating singleton references to Godot objects? I’m aware that the use of singletons is generally discouraged, but there are instances where they simplify our work. I guess that's how they implement fmt.printf().

The memory management approach in gd is something I’ve never encountered before, so I anticipate some misuse on my part. This is a concern for me. While I understand that this is by design in gd, I personally prefer the way Godot C# handles these pointers. It wraps them with a garbage collected object, allowing them to be dereferenced when the wrapper is collected by the GC. I won't switch to C# though, I already had too many Unity projects to realize its gc design is fundamentally bad for games.

I believe that if someone opts to use Go in game development, it implies they are willing to accept a reasonable amount of GC allocation. Otherwise, they would likely prefer to use C++, Rust or even Zig. In my view, tracking a reference count pointer is a reasonable GC allocation.

[Splizard]

@ShirenY please check out the latest iteration, would love some feedback, I've renamed gd.Context to gd.Lifetime (preserved an alias for backwards compatibility) and made it optional in method arguments. Instead you should use the builtin lifetime values in gd.Class which are Temporary (only live until we return back to Godot) and KeepAlive (stays alive as long as the class).

[ShirenY]

Hi @Splizard , the new example code is much clearer now. I think this API is a better version. The lifetime feature now feels like an allocator to me. Thank you for the great work.

I haven't looked into the lifetime mechanics yet, but do you think lifetimes are thread-safe? Since there are chances that Godot callbacks, like _process() and _physics_process(), will run in different threads at the same time.