Swift currently uses Bus system for broadcasting the messages among the apps.
However, it could be implemented with queued connection mechanism of Qt.
How the feature is implemented
Current system:
An app emits broadcastRequested signal with a bus name and a message.
Swift routes it to the designated Bus, and push the message into its message queue.
When the control flow switches to the Bus's queue consumer thread, the message is popped, and the received signal of the Bus is emitted.
Swift routes it to the subscriber apps' received signals.
Suggested system:
Same.
broadcastRequested signal is connected as QueuedConnection, so it is queued in the main thread's queue.
When the connected slot is executed by the main thread's event loop, it emits the received signal of the subscriber apps.
Additional context
The reason why we should use the queued system is that an app may abuse the broadcasting.
Imagine:
An app broadcasts a message.
The app itself subscribes it, and as a result, it broadcasts the same message again.
Then it will induce an infinite loop, freezing the GUI.
If we use the queued system, the events between each broadcast can be handled, since the control flow always returns back to the event loop immediately after broadcasting.
Feature you want to implement
Swift currently uses
Bus
system for broadcasting the messages among the apps. However, it could be implemented with queued connection mechanism of Qt.How the feature is implemented
Current system:
broadcastRequested
signal with a bus name and a message.Bus
, and push the message into its message queue.Bus
's queue consumer thread, the message is popped, and thereceived
signal of theBus
is emitted.received
signals.Suggested system:
broadcastRequested
signal is connected asQueuedConnection
, so it is queued in the main thread's queue.received
signal of the subscriber apps.Additional context
The reason why we should use the queued system is that an app may abuse the broadcasting. Imagine:
If we use the queued system, the events between each broadcast can be handled, since the control flow always returns back to the event loop immediately after broadcasting.
See also: #6.