Replymessage unavailable
In Python, if you have a global settings class and you're using multiple threads (main thread plus one QThread would count), that both access the settings, and at least one of them is altering the settings (as in, it's not just constant settings that are set once before the threads start), in *Python* with the GIL involved, I believe you don't really need to worry about corruption (reading a settings value while it is in the middle of being updated), because the GIL will gate that. However, if threaded C++ code is involved, the GIL is out of the picture in that thread, and your python code could be reading a value that is in the middle of being updated.
This is where Signals and slots are useful across QThread boundaries, as the slot call is actually done on the thread that owns that slot (Every QObject has a thread it belongs to, and the slot is part of a QObject), so, there's no concern of corruption given that only that one thread manages the data.
How it works is that an event for the signal gets created on the receiving object's QThread's event queue, and when the thread is servicing it's event queue and that event comes up, the event queue processing calls the slot.
The queue processing itself is guarded by mutexes behind the scenes.