Can't call node function from a thread

[RitleDev]

Godot version

4.1

System information

Windows 11, Godot 4.1.2

Issue description

Previously in Godot 4.0.0 it was possible to call functions like "get_children()" or "get_parent()" within a thread without errors (although this method wasn't thread safe I was okay with it because the functions only read data). Now (in Godot 4.1.2), as I try to call those functions an error shows up telling me to use "call_deferred". this doesn't help me solve the problem because call_deferred always returns null and I can't get any data back to the thread.

An example of the error I get:

  <C++ Error>    Condition "!is_readable_from_caller_thread()" is true. Returning: (Vector3())
  <C++ Source>   scene/3d/node_3d.cpp:249 @ get_global_position()

While it helps the code become more thread-safe I suggest to make an option to make this error a warning or simply ignore it in the project settings so that some of my older projects will continue to work in the newer versions.

Am I missing something? I couldn't find any solution other than editing long code structure and losing performance to get rid of the errors.

Steps to reproduce

I added a simple script that shows the issue with a test project:

extends Node2D

# Work-around to get the child node outside of the thread
@onready var child = get_child(0) 

var a: Thread
var b: Thread

func _ready():
	# Case A shows writing and the error when reading
	a = Thread.new()
	a.start(_threaded_func_A)
	
	# Case B shows reading
	b = Thread.new()
	b.start(_threaded_func_B)

func _threaded_func_A():
	# In this case call deferred will work and solve the issue.
	child.call_deferred("set_visible", true)
	
	# Will only work in Godot 4.0.1 (tested)
	print(get_child(0).visible)
	

# Should print the visibilty state but doesn't
func _threaded_func_B():
	# In this case call deferred won't work and require a work-around.
	# The first call deferred will return null.
	print(call_deferred("get_child", 0).call_deferred("get_visible"))

func _exit_tree():
	a.wait_to_finish()
	b.wait_to_finish()

Minimal reproduction project

Test project:

https://filebin.net/dhp7bjgojfjrhvfl

[KoBeWi]

You can use Thread.set_thread_safety_checks_enabled(false) to disable the safeguards, but then you are on your own to correctly call the methods.

[RitleDev]

Thank you @KoBeWi, this works well, unfortunately it only solves half the problem. For write calls (like add_child), the safety checks still apply and it can reduce performance in some cases forcing users to use "call_deferred".

In addition, Thread.set_thread_safety_checks_enabled(false) can't be called from the main thread for some reason.

  <C++ Error>    Condition "::Thread::is_main_thread()" is true.
  <C++ Source>   core/core_bind.cpp:1264 @ set_thread_safety_checks_enabled()
  <Stack Trace>  main.gd:8 @ _ready()

The function must be called from a different thread like so:

var a: Thread

func _ready():
	# Testing
	a = Thread.new()
	a.start(_threaded_func_A.bind(a))  # Passing the thread as an argument to disable safety checks

func _threaded_func_A(a: Thread):
	# can only set the safety checks within a thread that isn't the main thread
	a.set_thread_safety_checks_enabled(false)
	
	
	# Will now work in Godot 4.1.2 (tested)
	print(get_child(0).visible)
	
	# Will only work with call_deferred (just calling the function will result an error)
	var control_node_test= load("res://control.tscn")
	call_deferred("add_child", control_node_test.instantiate())
	
	# This will give an error in 4.1.2
	#add_child(control_node_test.instantiate())

func _exit_tree():
	a.wait_to_finish()

I think Thread.set_thread_safety_checks_enabled(false) should also disable the write calls safety checks. Or instead, that a different function will does so. It breaks older projects and requires manual refactoring of code while also sacrificing performance. While not being thread safe, in some cases it doesn't really matter.

(I have a project that suffers from this problem, I had to refactor it which took a long time to find all the write calls. After refactoring, the performance decreased significantly.)

[AThousandShips]

It breaks older projects and requires manual refactoring of code while also sacrificing performance. While not being thread safe, in some cases it doesn't really matter.

We shouldn't sacrifice thread safety because it requires work to update code that isn't safe, this isn't optional

Note also that just because there weren't any checks in previous versions doesn't mean the behavior is not bad code, the code should have been thread safe to begin with, the only change is enforcing it

[RitleDev]

I agree it helps most users have better and safer code, but it takes away the freedom to manage it manually for more advanced purposes. For example, some threads will only call functions for nodes/resources that are not shared between other threads and the nodes that are shared will be handled using Mutex. I'm unfamiliar with the way the scene tree is working and whether this is possible in 4.1.2.
I did have a project that worked that way in 4.0.1 and It's just sad for me to see this functionality go away.

[AThousandShips]

But adding and removing nodes from the tree isn't safe, no matter if you use mutexes, that's not something you can make thread safe with those methods

The issue here is that you're not only synchronizing and risking issues with your code, but with the engine itself, which you cannot prevent issues with, the engine will operate on nodes and therefore they shouldn't be manipulated in thread unsafe ways

[KoBeWi]

Thread guards were added to allow processing nodes in threads. You can offload branches of your scene tree to a thread (using process_thread_group property). This would be super brittle if it wasn't safeguarded properly.

[RitleDev]

Your answers are much appreciated, thank you😄