Signals are delayed on X11?

[wysota]

In consequence, doesn't it mean that you should ALWAYS do that, whenever you are using threads?

No, that's not always desired. For instance if the thread object has a parent, you can't push it to another thread. Furthermore the thread object is only a controller of the thread so it doesn't have to always be tied up closely to the thread itself.

So if I understand right, signals between threads are always queued by default, no matter if it's between a worker thread and the main thread or between two worker threads.

Yes, that's right. Read about "auto connections" of signals.

The difference it makes is that if a thread handles its own events, you eliminate the possibility of the main thread calling a slot of a worker thread at the wrong time. Is this correct?

Yes.

As performance is somewhat crucial, I wanted to try to find a way without mutexes. I would prefer a thread not to block and wait for a mutex to open, but to go ahead and calculate the next joint angles in the meantime.

So use tryLock() instead of lock() on the producer side.

Another thing about mutexes that bothers me is that they need to be global variables known to both threads.

That doesn't have to be true. You can have a mutex within a singleton class.

The most elegant solution would be something completely contained in one thread, without the other knowing about it.

If that was the case, you wouldn't be accessing the variable you want to protect from another thread. If you want an elegant solution, consider using shared memory (QSharedMemory) to transfer data between threads or processes. You can then split your application into two separate applications - one for performing calculations and the other for driving the robot.