Nominate our 2022 Qt Champions!


  • 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?

  • Moderators

    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.

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

  • Moderators

    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.