Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix deadlocks related to ClassDB queries about global classes #98963

Merged
merged 1 commit into from
Nov 10, 2024

Conversation

RandomShaper
Copy link
Member

@RandomShaper RandomShaper commented Nov 8, 2024

ClassDB::can_instantiate() and other reflection methods deadlock if the type is an script global class, when such script indirectly uses a not-yet-registered class. The reason is the ClassDB read lock is still held when invoking the ResourceLoader to load the class script, which may in turn need to lock for writing (for the class registration).

In particular, this happens with some types related to animation tree, that aren't registered at engine startup, but can happen with others, especially ones from the user. Registration statements are also added for the animation-related types that were lacking them.

(Better reviewed disabling whitespace diff.)

Version for 4.3 submitted as #98964.

@Mickeon
Copy link
Contributor

Mickeon commented Nov 8, 2024

Is it truly truly necessary to expose AnimationNodeEndState and AnimationNodeStartState?

`ClassDB::can_instantiate()` and other reflection methods deadlock if the type is an script global class, when such script indirectly uses a not-yet-registered class. The reason is the `ClassDB` read lock is still held when invoking the `ResourceLoader` to load the class script, which may in turn need to lock for writing (for the class registration).

In particular, this happens with some types related to animation tree, that aren't registered at engine startup, but can happen with others, especially ones from the user. Registration statements are also added for the animation-related types that were lacking them.
@RandomShaper
Copy link
Member Author

If they aren't meant to be exposed, we can use register them as internal.

Elaborating, the deadlock, when related to these classes, can be avoided either by the changes to ClassDB or by having the classes registered upfront. However, my rationale was that, given they will be registered anyway when first used (initialize_class()), we should just pre-register them anyway. Moreover, if we want to keep them internal, explicitly registering them is a must.

Pushing with the change.

Copy link
Member

@adamscott adamscott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.

Copy link
Member

@clayjohn clayjohn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fine to me.

Ideally there would be some way for us to tell when a class is missing registration. But this seems fine for now

@Repiteo Repiteo merged commit 323b2d5 into godotengine:master Nov 10, 2024
20 checks passed
@Repiteo
Copy link
Contributor

Repiteo commented Nov 10, 2024

Thanks!

@RandomShaper RandomShaper deleted the fix_classdb_deadlock branch November 11, 2024 07:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants