qtconnectiontype
-
first,does QMediaPlayer::play() plays in another thread?
I tried the audio module of SFML, it plays on another thread, is QT's audio the same?second, Qt::ConnectionType::BlockingQueuedConnection blocks other thread until the sender returns, how about blocking on the same thread?
-
I'd be surprised if
QMediaPlayer::play()starts its own thread, I can't be sure though. You could check its source if it is important to know.On your second question: blocking on the same thread doesn't make any sense. If the receiver is in the same thread as the sender, the signal-slot connection is executed directly as a function call (Qt::AutoConnection = Qt::DirectConnection), if they are on a different threads the slot execution is queued in the event loop (Qt::AutoConnection = Qt::QueuedConnection). If the sender and receiver are in different threads it makes sense to wait for the slot's execution in some cases.
Imagine what happens if there was a possibility to queue and block in the same thread:- The slot execution is queued.
- You block the thread to wait for the slot to finish (thus blocking the event loop, and the slot is never invoked).
Kind regards.
-
@kshegunov i dont get what will happen if the connectiontype is Qt::QueuedConnection. i know it will qeued but can you explain it?
-
@Lorence
When a signal is emitted that is connected to a slot through a queued connection, the actual invocation is deferred - an event is put into the event queue that belongs to the thread the receiver object lives in for later processing. This is why when you have a multithreaded application the slot is executed in the thread where the receiver lives in, and not in the thread where the actual signal was emitted.Here in the documentation is a more complete discussion.
