qtconnectiontype

[Lorence]

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?

[kshegunov]

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:

1. The slot execution is queued.
2. You block the thread to wait for the slot to finish (thus blocking the event loop, and the slot is never invoked).

Kind regards.

[Lorence]

@kshegunov i dont get what will happen if the connectiontype is Qt::QueuedConnection. i know it will qeued but can you explain it?

[kshegunov]

@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.