Cache singleton pointers

[Bromeon]

GDExtension API to fetch singletons

There is an FFI function to fetch a singleton:

typedef GDExtensionObjectPtr (*GDExtensionInterfaceGlobalGetSingleton)(GDExtensionConstStringNamePtr p_name);

Notably, this returns null if the singleton is not yet initialized (before a certain init stage).
What we need to test is whether it also returns null after a certain deinit stage.

---

Caching

Fetching these pointers via FFI + Godot lookup every time a singleton API is called shouldn't be necessary. Thoughts:

• One way is to cache by singleton name / class ID / type ID, in a Rust-side global HashMap.
• As singletons tend to be accessed from multiple threads, we'd need a locking strategy.
• We can optimize this, so that during "fully initialized" (after MainLoop init), we assume the hashmap doesn't change. It would need an AtomicBool (for the "fully initialized" flag accessed from different threads), after that a raw hashmap access. Or a Mutex if that's faster.
• We'd also need to see what key to use. GodotClass::class_id() retrieves the ID from a static OnceLock<ClassId> which should be pretty fast. It's a bit a shame that there's no good compile time solution (const_type_id is nightly, and even crates emulating it will need the hash computation).
• Blazingly fast would be to do it directly via trait, not needing hashmaps at all. Since all singletons are statically known via Singleton trait, we can override the singleton() method (or add another one) to store a static OnceLock<Something<Gd<T>>>. We'd somehow need to get the thread safety sorted, and make sure to have an extra check whether the singletons is initialized (already + still).
• I would not cache any dynamic singletons registered via Engine::register_singleton, or registered in GDScript.

[Yarwin]

Since all singletons are statically known via Singleton trait, we can override the singleton() method (or add another one) to store a static OnceLock<Something<Gd<T>>>.

I think it is the best option. Godot on its side stores singletons in a big hashmap, so duplicating it seems a little weird.

We'd somehow need to get the thread safety sorted,

I think we can treat docs as a source of truth and simply provide them in some kind of wrapper: https://docs.godotengine.org/en/latest/tutorials/performance/thread_safe_apis.html:

Most Global Scope singletons are thread-safe by default. Accessing servers from threads is supported.

As singletons tend to be accessed from multiple threads, we'd need a locking strategy.

Why? Godot guarantees that global scope singletons are thread-safe by default and accessing them from threads is supported. Moreover it is a fool errand – we just can't provide an unique access. I would treat it as one of the guarantees that one buys into with unsafe impl ExtensionLibrary.

and make sure to have an extra check whether the singletons is still initialized .

Why? Which built-in Godot engine singletons might be deinitialized before the extension? What is minimal reproduction for such a case? Manual removal (or unregistration) of most singletons is an user error and should be treated as an error state.

and make sure to have an extra check whether the singletons is already initialized

I think we might skip this case, as we have been so far – we should provide some API to try getting a singleton instead.

[Bromeon]

The thread safety here is not about accessing the singletons themselves, but for the hashmaps.

If we go with a trait instead, there's still an init step needed at some point. Maybe we can guarantee all are initialized sequentially on the main thread (and later deinitialized), so reads in between would be safe. But it's a bit hard to guarantee that e.g. unregistration can never coincide with an access from another thread... so conservatively we'd need some sort of lock.