Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. qtconnectiontype
QtWS25 Last Chance

qtconnectiontype

Scheduled Pinned Locked Moved Unsolved General and Desktop
qmediaplayerconnectqueuedconnectio
4 Posts 2 Posters 2.0k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • L Offline
    L Offline
    Lorence
    wrote on last edited by Lorence
    #1

    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?

    1 Reply Last reply
    0
    • kshegunovK Offline
      kshegunovK Offline
      kshegunov
      Moderators
      wrote on last edited by
      #2

      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.

      Read and abide by the Qt Code of Conduct

      L 1 Reply Last reply
      0
      • kshegunovK 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.

        L Offline
        L Offline
        Lorence
        wrote on last edited by
        #3

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

        kshegunovK 1 Reply Last reply
        0
        • L Lorence

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

          kshegunovK Offline
          kshegunovK Offline
          kshegunov
          Moderators
          wrote on last edited by kshegunov
          #4

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

          Read and abide by the Qt Code of Conduct

          1 Reply Last reply
          0

          • Login

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • Users
          • Groups
          • Search
          • Get Qt Extensions
          • Unsolved