With recursive mutex is emitting a signal "safe" now and can be immediate?

[ahayzen-kdab]

Existing state

• We prevent multiple threads from calling the Rust object
• Signals are considered "safe" if they are queued on the event loop, this was to prevent a deadlock if you have a signal connected to a slot

This creates problems because property changes emit one event loop later, and create other latencies. When now the behaviour is less likely to happen and is defined behaviour.

Proposed changes

Now that we have a recursive mutex we might be able to improve the limitations

• Change property changes to be immediate
• Change emit_queued to just emit and be immediate
• If you want queued then use qt_thread.queue(...)
• Ensure that emit is mutable
  • This ensures the same checks that Rust does, as then it's like calling another mutable function, so should be "safe"

Assumptions

• A deadlock is considered "safe" as it's defined behaviour (they would have to manually i C++ call the same qobject from another thread as the result of a signal)
• Also note that Qt connections automatically queue signal/slots when the QObjects are in different threads, so this protects the issue in most cases and would require the C++ developer to ignore this.

[ahayzen-kdab]

Yes! And this has landed now :-)