Executing Python code is not limited to the main thread, we do it in other threads for render engines and python drivers for example.

For me the deadlock looks like this: P3135. The problem is that the thread is trying to execute Python code will the main thread is still holding the global interpreter lock.

For similar recursive and threaded Python calls we use BPy_BEGIN_ALLOW_THREADS in the RNA API. Like this: P3136. But I haven't checked if it's the only place that would need this.

@Brecht Van Lommel (brecht) but the issue here is that there could be several IDs of the same type processed concurrently, and there is nothing in a custom py-defined getter/setter that prevents them to access data from another ID, or any other kind of stuff breaking thread safety?

C-defined 'official' RNA code is supposed to know it should not access data outside of the owner ID, but python code can do whatever it wants :|

This patch only executes the affected datablocks on the main thread, while other datablocks are still threaded. If a callback on the affected datablock reads from another type of datablock, it's also not threadsafe. So you'd need to make the whole thing single threaded, which seems like a big cost.

On the other hand, RNA get/set are already assumed thread safe by the depsgraph (for example for animation curve evaluation, not even Python drivers). And there is some thread safety between multiple threads executing Python, as calls into the Blender API will be protected by the GIL.

So while you can break things when get/set access other datablocks, I'd rather we add a note to the API docs that get/sets should only access data within the datablock.

Would not mind getting a second opinion from @Sergey Sharybin (sergey) or @Campbell Barton (campbellbarton) though.

So while you can break things when get/set access other datablocks, I'd rather we add a note to the API docs that get/sets should only access data within the datablock.

At least for now we do need to add such a note. Otherwise if one uses such custom getter and animates the custom property the DEG will not handle it properly since there is no relation in the DEG to ensure order of evaluation.

For the initial report, I'm not sure why the rna_access_threadsafe is limited to armatures only. Seems that BPy_BEGIN_ALLOW_THREADS/BPy_END_ALLOW_THREADS will be more generic solution.
Or, maybe even extra work is needed to fully resolve custom getters/setters since those might be used by animation system from multiple threads.